I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go.<p>The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error value on errors. Most Go error handling is exactly that, written out. Rust lacks a uniform error type. Rust has three main error systems (io::Error, thiserror, and anyhow), which is a pain when you have to pass them upward through a chain of calls.<p>(There are a number of things which tend to be left out of new languages and are a pain to retrofit, because there will be nearly identical but incompatible versions. Constant types. Boolean types. Error types. Multidimensional array types. Vector and matrix types of size 2, 3, and 4 with their usual operations. If those are not standardized early, programs will spend much time fussing with multiple representations of the same thing. Except for error handling, these issues do not affect web dev much, but they are a huge pain for numerical work, graphics, and modeling, where standard operations are applied to arrays of numbers.)<p>Go has two main advantages for web services. First, goroutines, as the OP points out.
Second, libraries, which the OP doesn't mention much. Go has libraries for most of the things a web service might need, and they are the ones Google uses internally. So they've survived in very heavily used environments. Even the obscure cases are heavily used. This is not true of Rust's crates, which are less mature and often don't have formal QA support.
For me the main advantage of Go over Rust is compilation speed. Then compared with Go Rust still rely on many C and C++ libraries making it problematic to cross-compile or generate reproducible builds or static binaries.<p>The minus side of Go is too simplistic GC. When latency spikes hit, there are little options to address them besides painful rewrite.
What kind of apps are you writing where GC spikes matter?
I've run into GC pauses, I think in many (most?) cases there is some class of bulky data that you can either move into slices of pointer-free structs (so the GC doesn't scan them) or off-heap entirely. The workload where GC is slow is also likely prone to fragmentation so whatever the language you'll have to deal with it.
Isn’t it somewhat easy to remove allocations in Go? I haven’t had to “rewrite” as such, but rather lifting some allocation out of loop. Am I misunderstanding the scenario?
> Rust lacks a uniform error type<p>Rust has practically one error, it's the Error trait. The things you've listed are some common ways to use it, but you're entirely fine with just Box<dyn Error> (which is basically what anyhow::Error is) and similar.
Surely you need an alternative to Box<dyn Error> for reporting memory allocation failures?!
Having many semantic options for error usage is functionally the same as having many error types, except worse.
They all convert seamlessly, and the enums make the branches explicit. Don't even need to check the documentation to find which errors supposedly exists like in Go with its errors.Is, errors.As, wrapping and what not.<p>An easy rule before you make a knowledge based choice is Thiserror for libraries, helping you create the standard library error types and Anyhow for applications, easy strings you bubble up.<p>Or just go with anyhow until you find a need for something else.<p><a href="https://crates.io/crates/anyhow" rel="nofollow">https://crates.io/crates/anyhow</a><p><a href="https://crates.io/crates/thiserror" rel="nofollow">https://crates.io/crates/thiserror</a>
I’ve repeatedly tried using Rust and the error handling has tripped me up every time and has been ~90% of the reason for moving a project back to another language. I’m sure I’m just holding it wrong, but what I run into usually goes something like this (mind you, I have read the Rust book):<p>* Someone tells me to use enums for errors, in a comment like yours<p>* I try writing the enums by hand, implementing the error trait<p>* I realize that in order to use the ? operator I need to implement From on my errors (I’ve read so many comments about how awfully verbose Go errors are, so I assume I’m supposed to use ? in Rust). There are also some other traits IIRC but I’ve forgotten them.<p>* I realize that this is pretty tedious, manual work, so someone points me to thiserr or similar<p>* Now I’m debugging macro expansion errors and spending approximately the same amount of time<p>* I ask around and someone tells me not to bother with thiserr and to just write the boilerplate myself or else to use anyhow or boxed errors everywhere<p>* I try using boxed errors everywhere, which works, but now I have all of these allocations which feels like I’m doing something that will bite me later. Oh well, but now I need to annotate my errors so I can figure out what is actually happening. I guess I should use anyhow for this?<p>* Anyhow mostly works but this is approximately as verbose as the Go error handling that I’m told is Very Bad, and when I ask for code review most Rust people are telling me not to use anyhow because errors should be enums, at least in the API surface<p>I’m sure I’m doing it wrong, but as with many things in Rust, the Right Way is so rarely clear and every other Rust person gives different advice about how to solve my problem and the only thing they seem to agree on is that Rust has an easy solution and that I’m following the wrong advice. (Similarly when I had lifetime problems and half the community told me to just use clone and Rc everywhere until I had performance problems, so instead I just had different static analysis problems).<p>I don’t love Go’s error handling. It feels like there has to be something better than its runtime-typing. But it largely gets out of the way—creating an error is just implementing the Error method, and if you need a concrete type you use Is/As/AsType. Wrapping is fmt.Errorf. All of this is built into the stdlib and used pretty ubiquitously across the ecosystem—I don’t run into “this dependency uses a different error framework”. Error handling is marginally more verbose than with Rust if you are actually attaching context in both, and neither solves the problem of which call frame attaches the context about specific function parameters (e.g., which level of error context specifies that the function was called with path “/foo/bar.baz”). It’s terrible, but it works—feels like the least bad thing until the Rust community can arrive at some consensus and document it in The Book. Or maybe I just need to try again in the LLM era?
How come you get macro expansion errors? Or is it because you write incorrect syntax in the enum error definitions?<p>The example on the docs page is quite clear:<p><a href="https://docs.rs/thiserror/latest/thiserror/#example" rel="nofollow">https://docs.rs/thiserror/latest/thiserror/#example</a><p>Including all kinds of errors: Strings, tagged unions and automatically converting from std::io::Error with added context.<p>That one page document is the entire documentation for the thiserror crate.
I was a big fan of go for a while. Though now that I have programmed more swift and rust recently, having a compiler that doesn’t protect against null pointer deferences or provide concurrency safety guarantees feels a little prehistoric.<p>Though go certainly did a much better job than rust on the standard library front.
Standard library is something you have to maintain for all eternity, with identical API. It had been argued that some concurrency primitives like channels would have been better outside of std (for rust, to be clear). Once dependency management is solved, a small std is beneficial.
> <i>you have to maintain for all eternity, with identical API</i><p>People always tout this as a huge reason for not wanting a too big std in Rust (or "too useful" either), but IMHO that's just talking about reaching theoretical optimals, while leaving the community for years without good guidance via providing a opinionated practical and pragmatic way of doing things. Which I find to be a very unhelpful stance for a tool such as a programming language.<p>If a design of some std package didn't pass the test of time, and a new iteration would be beneficial, the language can leave its original API version right there, and evolve with a v2, with an improved and better thought out API after learning from the mistakes of v1.<p>Prime example: "hey we found that math/rand had some flaws, so here is math/rand/v2". A practical solution, and zero dramas as a result of having rand be part of std.
I use go because of the large and useful stdlib. I rarely have to reach for an external library, and even then I only consider libraries that are very popular. If a library isn’t available, I’ll just write my own, using the stdlib. I recently used the awesome crypto library to implement an envelope encryption system, I didn’t need anything outside of the stdlib or Google’s x library (x is effectively the experimental stdlib).<p>Having too much external code, like npm or rust crates, seems like a nightmare for me.
I agree! The line early on about this being for backend services caught my attention. I love the Rust language and use it for embedded firmware and PC applications, but still use Python for web backends, because Rust doesn't have any tool sets on the tier of Django (Or Rails). It has Flask analogs, without the robust Flask ecosystem. I have less experience with Go, but would choose it over Rust for web backends, for the same reason you highlight: The library (including framework) ecosystem. I am also not the biggest Async Rust fan for the standard reasons (The rust web ecosystem is almost fully Async-required).
For backend web dev, there are advantages. I really like Axum's use of typing:<p><pre><code> pub async fn dataset_stats_handler(
Path(dataset_id): Path<String>,
Query(verbose): Query<bool>,
) -> impl IntoResponse {
...
}
</code></pre>
With a route like:<p><pre><code> .route("/datasets/{dataset_id}/stats", get(dataset_stats_handler))
</code></pre>
…the "dataset_id" path variable is parsed straight into the dataset_id arg, and a query string "verbose" is parsed into a boolean. Super convenient compared to Go, and you type validation along with it.<p>Many other things to like: The absence of context.Context, the fact that handlers can just return the response data, etc.<p>What I don't like: Async.
go is slightly more verbose (surprise) but you can achieve the same thing using struct binding in gin:<p><pre><code> type DatasetStatsQuery struct {
Verbose bool `form:"verbose"`
}
func DatasetStatsHandler(c *gin.Context) {
datasetID := c.Param("dataset_id")
var query DatasetStatsQuery
if err := c.ShouldBindQuery(&query); err != nil {
c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
return
}
// query.Verbose == boolean
}}</code></pre>
Rust does not have three error systems. It has one: the Error trait. io::Error is one of many that implement it (nothing special about it). Errors defined via thiserror also implement it.<p>“Anyhow” just allows you to conveniently say “some Error” if you don’t care to write out an API contract specifying types of errors your function might spit out.
thiserror and anyhow are just std::error with extra steps. Note that io::error is just a specific std::error.<p>The entire point in Rust is that you wrap Error impls with other Error impls, or translate one impl into another using a match. I've found this is far more flexible and verifiable than most other languages, because if you craft your error types with enough rigor, you can basically have a complete semantic backtrace without the overhead of a real backtrace.<p>I use thiserror a lot to help with my impls. Notably, all it does is impl Display and Error. It's not a specific other paradigm because it basically compiles out, it's just a macro.<p>Anyhow is perhaps the closest one to another paradigm because it allows you to discard typed information in favor of just the string messages, but it still integrates well with Errors (and is one).
I find Elixir's memory and threading models much more compelling than Go's for web services. There are many great libraries for Elixir as well, but if you need something else, Elixir makes rolling your own libraries very easy. I'd recommend giving Elixir a try, if you haven't already.
Praising go for how it handles errors, when it's even worse than C where the compiler at least warns you if you're ignoring return values of calls. That's a new one.
Linters are available to catch you before you compile - with Go<p>Generally speaking there has to be a mechanism for optional handling of return values, in Go you can ignore everything (ew), you can use placeholders `_`, or you can explicitly handle things - my preference.<p>If you say "Well in C you have to handle the returns - I am not across C enough to comment, but I will ask you - Does C actually force you, or does it allow you to say "ok I will put some variables in to catch the returns, but I will never actually use those variables" - because that's very much the same as Go with the placeholder approach<p>edit: I am told the following is possible in C<p>trySomething(); // Assumes that the author of trySomething has not annotated the function as a `nodiscard`<p>(void)trySomething(); // Casts the return(s) to void, telling the compiler to ignore the non-handling<p>int dummy = trySomething(); // assign to a variable that's never used again<p>I welcome correction
This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with most of the stuff on the go project covered by the stdlib whereas I think the rust project is over 400 despite asking for <i>just</i> rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui), the last of which is by far the worst offender but even without it, it’s still close on 100 which is crazy. If there were (and maybe there are, I just haven’t found them) decently maintained alternatives to the rust crates that <i>actually have a sane dependency approach</i>, I’d feel much better. I’m just trying to not shai hulud my system, and the rust-web people seem to want to turn cargo into npm in that regard.
Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo.<p>I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alternative.
Unfortunately the 0.x version has pervaded because of community cargo culting claiming that versioning is easier with 0.x than with major version numbers > 0. Personally I find that hard to believe, especially given packages like Tokio and anyhow (still at v1) make it work and there’s others that are >v1.<p>That is to say 0.x doesn’t necessarily mean unmaintained, it can also mean “I don’t want to have to think about how to version APIs / make guarantees about APIs). Eg reqwest is very widely used and actively maintained yet is still at v0.13.
> claiming that versioning is easier with 0.x than with major version numbers > 0<p>I think it's less that versioning is claimed to be easier with 0.x versions, and more that some people have got into their heads that 1.0 signals either "permanently stable" or "no new versions for several years" and they don't want to commit to that yet.<p>I do wish more crates would 1.0 (and then 2.0, etc).
There is good reasons to break out projects into multiple crates. It makes reusing functionality elsewhere easier. It makes it easier to reason about behavior. It makes it easier for LLMs to understand (either working within the crate or consuming as an api surface.) So you end up with projects that have multiple crates inside the same workspace and it really blows up dependency count.
> rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui)<p>Does any language, except like Java, exist with a standard library comprising matching that?<p>Also, keep in mind that Tauri itself is 14 crates, where each one shows up in your build tree.<p><a href="https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml" rel="nofollow">https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml</a><p>And Ratatui is 6:<p><a href="https://github.com/ratatui/ratatui/blob/main/Cargo.toml" rel="nofollow">https://github.com/ratatui/ratatui/blob/main/Cargo.toml</a>
Python has sqlite3[0], curses (tui) [1], and tkinter[2] in the stdlib.<p>[0] <a href="https://docs.python.org/3/library/sqlite3.html" rel="nofollow">https://docs.python.org/3/library/sqlite3.html</a><p>[1] <a href="https://docs.python.org/3/library/curses.html" rel="nofollow">https://docs.python.org/3/library/curses.html</a><p>[2] <a href="https://docs.python.org/3/library/tkinter.html" rel="nofollow">https://docs.python.org/3/library/tkinter.html</a>
The stdlib is the place where good ideas go to die.<p>And then you have httplib3 followed by httplib4.<p>In other words: I highly prefer the Rust approach.<p>It doesn't matter a lot whether I rely on the stdlib or another dependency to me.<p>It's a dependency after all.<p>People think just because it's the stdlib it's somehow better quality or better maintained, but these are orthogonal concepts.<p>In the end it depends solely on resources.<p>Sure, the stdlib may get more of these, but it may also grow fat and unmaintainable...
Package management is the bane of nearly every language/technology<p>Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?)<p>For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine)<p>There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseudo version, and, vendoring (which is a cache of known dependencies - which brings with it cache management problems)<p>I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.<p>Look at
Perl (cpan)
Java (maven, gradle)
Ruby (gems)
Go (dep, glide, vgo, modules)
Rust (cargo)
Node (npm, yarn, etc)<p>OSes too
Redhat (yum, rpm, etc)
Debian (apt)
Ubuntu (snap - god why????)<p>And so on
Interesting. I'm not very familiar with Go. What is the equivalent for Tauri in Go's stdlib?<p>Would it make sense to continue using Go for the frontend and doing only the backend in Rust for your user case?
Why is it worse to import a number of other packages that provide exactly the functionality you need, than to have a large standard library that provides some but not all of the functionality you need, requiring you to still use some large dependencies?
This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust.<p>Ultimately, <i>if you have to ask</i>, the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there are more programming domains where you want a managed runtime than ones where you don't.<p>That's not an argument for defaulting to Go in all those cases! There are plenty of subjective reasons to prefer Rust. I miss `match` when I write Go (I do not miss tokio and async Rust, though). They're both perfectly legitimate choices in virtually any case where you don't have to distort the problem space to fit them in (ie: trying to write a Go LKM would be a weird move).<p>The Rust vs. Go slapfight is a weird and cringe backwater of our field. Huge portions of the industry are happily building entire systems in Python or Node, and smirking at the weirdos arguing over which statically typed compiled language to use. Python vs. (Rust|Go) is a real question. Rust vs. Go isn't.
The use of LLMs has caused Rust usage to explode.<p>If youre not writing the code yourself and vibing away which I think most people generally are despite the disdain around here then why would you not choose the "more performant language" (I know that isnt necessarily reality but it is a common perception).<p>Go's managed runtime is less valuable when the LLM is perfectly happy to slap a bunch of stuff together for you to and approximate it and doesn't complain at all when writing async rust despite some of the rough edges.
I agree that agents make Rust a lot more tenable for less "kernel-and-browser"-demanding tasks than it was 4 years ago, but I do not agree that they eliminate the "managed vs. unmanaged runtime" question, and to the extent they influence any of this decisionmaking at all, you have to accept the notion of <i>not reading</i> the code. If you're reading it, it matters that Rust makes you do bookkeeping that managed runtimes avoid.
I think I'd be ok with node via purescript? But in general I think rust and go people should join forces against the evils of dynamic typing. Isn't type hinting finally considered best practice now? I think that is effectively an admission that it was a defect. And even with good ginting it is still worse than inference. Inference can let plenty of code go untouched on type changes, while still protecting against unindended type changes.
Us Node folks adapted typescript because we wanted static compiled types.<p>I wish TS had more of a runtime. The only thing I'm jealous of with regards to python is how seamlessly you can do JSON schema enforcement on HTTP endpoints. The Zod hoops are a constant source of irritation that only exists because the TS team is dogmatic.
LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:"<p><pre><code> "This is the area where Go genuinely shines, and it’s worth being precise about why"
"the lack of GC pauses is a genuine selling point"
"Humans are genuinely bad at reasoning about memory"
"There are cases where the borrow checker is genuinely too strict"
</code></pre>
tbc I don't think the article was fully AI-generated, just AI-assisted. If so, the author did a <i>genuinely</i> good job of it! No one else is commenting on it, so clearly it didn't detract much from the substance. It's just weird that this is becoming increasingly common, and increasingly hard to detect.
This is completely off topic now but, "it's worth being precise about ..." is a much stronger AI-ism than the usage of the word genuine.
I have to agree here, but I'm not sure why. I don't have any clue what makes something sound AI generated or not. I got to about here "Go is clearly working for a lot of people," -- before I became suspicious that it was AI-assisted (but also maybe I'm wrong and it's not AI-assisted, I am very bad at telling). It's more about vibes (ironically) than anything else in particular. If something "sounds" AI-assisted then I instantly lose interest even if the article itself is otherwise fine. I wish people were more ok with writing their own thoughts with how it comes to them.
I think the whole post is AI generated. The author could have given a draft as input and perhaps edited the output in a few places.<p>Take this paragraph as example:<p>> Go got generics in 1.18, and they’re useful, but the implementation has constraints (no methods with type parameters, GC shape stenciling, occasional surprising performance characteristics). Rust generics monomorphize, each instantiation produces specialized code with zero runtime cost. Combined with traits, this gives you real zero-cost abstractions.<p>Every sentence says something. Every sentence is important and holds its weight. I would expect that kind of writing from very specialized books or papers, not from a blog post. Also, it makes the post harder (and more boring) to read.
I've noticed LLM writing over the past year has had an unusually high tendency to talk about surfaces and, in particular, substrates. I don't expect LLM generated text to be anything other than rich with clichés. I simply wish we would all demonstrate a better editorial hand so we weren't reading the same voice, over and over.
Read migrating from one hype to another, developers never learn or change, do they??<p>It feels like yesterday when every single project was moving to Go just because it was the new hype, that was until Rust was born.<p>We are already seeing projects dumping migration to Rust because the grass is not always greener on the other side.<p>We will be seeing this again, "Migrating from Rust to XYZ"
If you have a green field, by all means write it in rust. If you have a brown field, and a functional profitable system, rewrite the parts that need rewriting in the <i>original</i> language, whatever that is, and carry on. Make your systems better in small measurable ways, with the language you know and a team you trust to implement it all. Anything else is a wasteful religious argument.
I already use Rust and don't have experience with Go, so this article maybe isn't super for me.<p>I do have one nitpick though: Stating that data races are "caught at compile time" in Rust feels like it is overstating the case, at least a little. It sounds a bit like its implying Rust can also handle things like mutual lock starvation, or other concurrency issues. When that's simply not the case. I know "data race" is technically a formal term, with a decently narrow scope, yet I still think it could be a bit clearer about it.
If verbosity is a main stickler, this is coming to golang 1.28 which will cut it down drastically:<p><a href="https://github.com/golang/go/issues/12854#issue-110104883" rel="nofollow">https://github.com/golang/go/issues/12854#issue-110104883</a>
"services that your organization relies on, that have high uptime requirements, that are critical to your business"<p>Kind of funny when your Rust service runs on Kubernetes.
It is also easier to make your code deterministic with Rust vs with Go, which is incredibly useful if you need to perform deterministic simulation testing + property-based testing. I recently wrote a Postgres-to-Iceberg data mirroring tool [1] in Go, but I ported it to Rust because I wanted the ability perform DST without fighting Go's runtime [2]. But if the domain is not critical that warrants DST, I would still pick Go over Rust any day.<p>[1] <a href="https://github.com/polynya-dev/pg2iceberg" rel="nofollow">https://github.com/polynya-dev/pg2iceberg</a><p>[2] <a href="https://www.polarsignals.com/blog/posts/2024/05/28/mostly-dst-in-go" rel="nofollow">https://www.polarsignals.com/blog/posts/2024/05/28/mostly-ds...</a>
I liked Rust before running a benchmark, but the gap between how effectively most LLMs write in Rust vs Go was still surprisingly large to me (especially in agentic harnesses where they can fix the initial environment issues). I've become a pretty big Rust evangelist after seeing that. We've had a lot of success writing batch processing tools in Rust to be called by our existing codebase, but haven't attempted a full production migration... yet.<p>I will say that many of the issues with Go in the article, especially re: nil handling are increasingly solved by thorough coding reviews with Codex. Better to not have the issue in the first place, sure, but these kinds of security bugs are becoming optional to developers who put in at least as much effort to review and understand code as they put into the initial design and execution.<p>Language data at <a href="https://gertlabs.com/rankings?mode=agentic_coding" rel="nofollow">https://gertlabs.com/rankings?mode=agentic_coding</a>
The detailed compiler errors and strong type system makes the change -> compile -> change loop simple for agents to handle. Rust provides very strong rails it forces users on to. Codex always manages to get something to compile.<p>The downside is that maybe it should fail sometimes when an idiomatic approach isn’t viable… instead it will implement something stupid that compiles and meets the request.
The weakness of Rust WRT LLMs is compilation times. LLMs code faster and hence spend relatively more time waiting for compilation than humans do, so on reasonably sized projects (e.g. 100k+ lines) Rust's ~10x slower compilation starts showing up as a bottleneck. If you're writing some critical infrastructure it makes sense to pay that cost, but if you're writing some internal service that's not publicly exposed to the internet then development velocity may be a bigger concern. (I'd argue that slow compilation also influences human development velocity, but for some reason developers very rarely try to quantify this.)
perhaps the oncall is better if you write your own services, but as an SRE / ops person who has to run other people's services, rust ones just generally seem to be worse: logs that are so verbose but seem to tell you nothing, statsd seems to be the only choice for metrics, contextless errors everywhere, memory "leaks" (more like runaway memory use) that the developers swear are impossible because it's rust, overall just less mature across services written by both in house and oss teams
Very nice write up! I am a fan of Rust and have little exposure to Go. That said, a couple of very minor points:<p>cargo audit is not built-in, it is 3rd party. (The comparison table near the top isn't clear about that, and the following text stating more is built-in for Rust than for Go might be confusing. I would suggest adding an asterisk to mark built-ins in that table.)<p>cargo watch has been in "maintenance mode" for some time. The author of that suggests cargo bacon instead.
I do like using Rust quite a bit, but the presence of arbitrary build-time code in build.rs is very risky until we get better at implementing dev-time sandboxing.
Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go.<p>This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust?<p>Per the article, you are getting 20-50% better more performance with Rust. Not worth it unless your team was already fluent in Rust. Now consider a scenario where your team uses AI exclusively to code, now you are spending more time and tokens waiting around to consume large rust builds. As far as I know this is an inherent property of Rust to have its safety guarantees.<p>I think Rust makes sense for a lot of cases, but for a small web service, overkill and unnecessary imho. If someone ported their crud app from Go to Rust I would question their priorities.<p>Again I am speaking more in terms of software engineering <i>economics</i> than anything else. Yes, I know in a perfect world Rust binaries are smaller, performance is better and code more “correct”, but the world is hardly perfect. People have to push code quickly, iterate quickly. Teams have churn, Rust, frankly is alien for many, etc.
Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.
> As far as I know this is an inherent property of Rust to have its safety guarantees.<p>From what I've seen, Rust's strictness is actually a huge win for LLMs, as they get much better feedback on what's wrong with the code. Things like null checking that would be a runtime error in Go are implied by the types / evident in the syntax in Rust.
> spending more time and tokens waiting around<p>Can you clarify how you're spending tokens on waiting? My understanding is that the LLM isn't actually necessarily doing anything while a build runs. The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens?
> The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens?<p>This. rust emits more information both in its output and the syntax itself more complicated requires more tokens.
Can you explain a bit about why token costs would favor Go and not Rust?
Go is more verbose, but Rust have more complex syntax which in practice require more tokens.<p>The big thing though is because builds are slower, you will end up waiting longer as tests are modified, rebuilt and run. This difference piles up fast.
> However in an agentic world go will win<p>This is Silicon Valley fantasy.
It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US
> Under heavy allocation, P99 latency tails are noticeably worse than a Rust equivalent that simply doesn’t allocate on the hot path.<p>Lmao so not an equivalent then? Standard glibc malloc, which is default in rust, will also similarly degrade albeit for different reasons.
The "when to enforce it" framing is what sticks with me. Go and Rust agree on safety, concurrency, simple deployment, but Go says "catch it in review" and Rust says "catch it before it compiles." The right answer depends entirely on how expensive a production incident is for you vs. how expensive slower iteration is.
I still think rustfmt made a mistake by going with four spaces. It's basically inferior for everything except forcing everyone to use the same indentation width, which is actually a downside, since I constantly encounter two-space indent codebases that I can't read and also can't change to four spaces because it's not tabs. Also translating spaces to tabs visually is undecidable thanks to alignment, while the inverse is not true. Ugh.
Go has shorter and more predictable GC pauses. If a reference count drops to zero in Rust, it may take an unbounded time to free all the things it refers to (recursively if necessary).
[dead]