> There’s no built-in goroutine-style preemption. Long CPU-bound work in an async task starves the executor; you offload to tokio::task::spawn_blocking or rayon instead.

I don't know why anyone uses spawn_blocking for CPU-bound tasks. It's clearly designed for blocking IO tasks. There's a reason why Erlang cordons them separately into Dirty CPU and Dirty IO schedulers.

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.

i like go because it's simple and just works. i like the error handling, if err != nil return err, i like the philosophy to focus using stdlib instead choose which libraries are the best for doing x. i like how go handle the concurrency like using channel or sync.waitgroup. i am very biased but someday i will also learn rust

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

I would add that Rust also has naming guidelines and sticking to them removes or at least minimizes the occurrence of another common topic of discussions on PRs/reviews.

In the article, if you were to mention & follow them GetUser() in Go becomes user() in Rust[1], not get_user().

[1] https://rust-lang.github.io/api-guidelines/naming.html#gette...

I was a Go engineer for years and have shipped a lot of Go. I never properly learned Rust.

Over the past year I've been using AI to write small Rust tools for myself — I barely read the code, and honestly it just works.

But for serious projects I expect to maintain long-term, I still pick Go. Today I want code I can actually own and reason about myself.

Give it a year or two and I probably won't be writing code by hand at all. Once the AI owns the code anyway, that reason disappears — and at that point Rust's guarantees win. So I suspect I'll end up leaning Rust.

Very nice write up! I am a fan of Rust and have little exposure to Go. That said, a couple of very minor points:

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.)

cargo watch has been in "maintenance mode" for some time. The author of that suggests cargo bacon instead.

Great writeup. The section on error handling differences is spot on, especially how Rust's Result type changes the way you structure application flow.

Read migrating from one hype to another, developers never learn or change, do they??

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.

We are already seeing projects dumping migration to Rust because the grass is not always greener on the other side.

We will be seeing this again, "Migrating from Rust to XYZ"

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.

[1] https://github.com/polynya-dev/pg2iceberg

[2] https://www.polarsignals.com/blog/posts/2024/05/28/mostly-ds...