The site you've read the article on. Built in one session. In Go.

I work with an AI that writes most of the code. The question everyone asks is which language to vibe in. Python is fast to start. Rust is correct by construction. Go is boring.

I choose boring. Here's why.

riclib, should that be 3 lines?

This is your project, is it not? Can you not simply tell the agent to cover 100% of the code?

Notably, types in TypeScript are also optional, but LLMs don't seem to have any problem generating fully type-safe code without `any` (though you do need to gently nudge them on occasion, or run a linter that forbids it). I don't see why they'd choke so hard on Mypy.

Go's ecosystem is especially weak in ML, stats, and any kind of scientific computation. I mean, do you really want Claude to implement standard battle-tested ML algorithms in Go from scratch? You'd be burning tokens and still get a worse result than if you'd just used Python.

I use Go to write CLI tools, but for ML work I'd rather have Claude generate Python.

The suitability of language hinges not only on its language design, but its ecosystem as well.

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