The case given here for ‘why Go, not Python’ is just as applicable for ‘why Rust, not Go’.

> The borrow checker catches real bugs. The type system is rigorous. The compiler says no, and when it says no, it’s right. The problem is that the compiler says no too much.

> When an AI writes Rust, the borrow checker fights the generated code. I — the human — spend my taste budget on lifetime annotations instead of architecture. Instead of saying “why do we keep both around?” — five words that collapse complexity — I’m saying “add a .clone() here” or “wrap this in Arc<Mutex<>>.” I’m using Layer 5, the most expensive layer, on problems the language invented.

These paragraphs are inconsistent. Either lifetimes catch real bugs — i.e. they reflect the ‘real’ (runtime) world, and when the compiler rejects some generated code it's because that code is buggy — or the language merely invented the problems they exist to solve and you're wasting your time thinking about them. (In my experience it's about 80:20 respectively, but for the level of code LLMs generate probably higher.)

> Go has goroutines. You write `go func()` and it works. Rust has colored functions.

Go also has coloured functions, but the only functions that are allowed to not be async are FFI. Go marks all functions as async just as JavaScript marks all return types as `any` — with the exception that sometimes Go is wrong and you have to remember where.

> One crate uses async-std. Now you have two runtimes.

Only if you start an async-std runtime. (There are compatibility options, too.) There are certainly occasional pitfalls when writing cross-runtime code in Rust, but relatively few these days, and not really the ones the article worries about.

> Come back to a Rust project after three months. Run `cargo update`. Half your transitive dependencies don’t compile because a trait bound changed in a crate you’ve never heard of.

If you lock your dependencies (which is in fact the case by default, and what you're explicitly opting out of by running `cargo update`) this doesn't happen. If you change the version of a Go dependency, it may also change API. Rust just has a tool to automate this workflow. If you choose not to use it you'll get the Go experience.

There are valid reasons (IMHO) to reject Rust for vibe coding (all else being equal). They're not these though.

Why I Vibe in Go, Not Rust or Python