I "Vibe" in all three to be honest. I've had good success, the key thing is, and I say this often, you have to think like an architect, and basically tell it how you want something built not just what you want built.

Last night I built a website from scratch. Not a landing page. A full blog with three-domain routing, animated video covers, an audio player with playlists, dark mode, RSS feeds, social cards, and a sticky sidebar with a lightbox. Seven commits. Zero test failures. One binary.

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.

> Mypy exists. Mypy is optional. Optional means it’s not there. I’ve never seen a Python project where mypy covers 100% of the code with strict mode. I’ve seen hundreds where it covers the 20% someone added last quarter. The other 80% is Any, all the way down.

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.

I use Node for one off vibe-coded stuff, that way I can't pretend it's not a piece of crap.

It depends on the use case. Go seems like a dream... until you have to work with dataframes or do any kind of ML work. Then it's a nightmare.

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

I read the first two paragraphs, found a bunch of fairly glaring errors, and got put off.

>It has type hints, which are optional, which means they’re not there.

I mean it is there, and it works.

I've also not had an AI make a dict key error in a while, but mostly as I use objects - haven't magic strings in code been bad for a while now?

Also llms are bad at architecture, not things like typing or keys. I'm really struggling with even opus having an absolute atrocious abstraction approach, and has made implementing business logic incredibly difficult. Borderline having to throw out days of work.

I found TypeScript and Node.js particularly have advantages as well

> The deploy script is 30 lines of bash

riclib, should that be 3 lines?

Add air for auto reload and ur golden

I write Rust only and never look back.

I have found C# has a the same advantages as Go when vibe coding.

[dead]

[dead]