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.
every page includes inline css, js etc. so each load it will pull all of that in each time. so each page transfer.
you could put the css and js parts that are common between them into separate files so that the browser can cache them and your users and server save some bandwidth.
happy to see most of it looks kinda decent. Not sure why you promote the site as being built in Go because its html, css and javascript. The backend can be go, but since it is not visible and theres no link to that code its impossible to see if its good or bad. the fact it does xyz doesnt really say anything about code quality..it just confirms the happy path works which is what AI is pretty good at.
it might be interesting to open it up for scrutiny and get some contributions if its good or some tips for footguns or bugfixes if there are such things.
not trying to discourage ofcourse :D and it sounds like a fun and rewarding project and ultimately i can navigate the pages just fine and it works ok on my connection regarding the bandwidth remark. (thats long run savings i guess, or handier when u receive higher volume traffic perhaps?)
Why use an obscure language like Golang when you can use Java? It is just as capable and boring as Golang but has an order of magnitude or two more available libraries, training data, and runtime support.
If you've only had exposure to one corner of the software industry then it's very easy to develop blinders. Not saying that this is what parent is guilty of but as somebody who has regrettably had this particular problem in the (thankfully distant) past I feel compelled to point out that this type of ignorance is sometimes just a side effect of one's circumstances.
As an example PHP still powers something like 75% of web sites and I've never once used it professionally. If I didn't know better I might think it dead.
> 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.
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.
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.
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.
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.
I'm also struggling with this: "The compiler is the floor. The human is the taste. The binary is the proof."
I'd initially go for parody but I'm not laughing (inwardly).
you could put the css and js parts that are common between them into separate files so that the browser can cache them and your users and server save some bandwidth.
happy to see most of it looks kinda decent. Not sure why you promote the site as being built in Go because its html, css and javascript. The backend can be go, but since it is not visible and theres no link to that code its impossible to see if its good or bad. the fact it does xyz doesnt really say anything about code quality..it just confirms the happy path works which is what AI is pretty good at.
it might be interesting to open it up for scrutiny and get some contributions if its good or some tips for footguns or bugfixes if there are such things.
not trying to discourage ofcourse :D and it sounds like a fun and rewarding project and ultimately i can navigate the pages just fine and it works ok on my connection regarding the bandwidth remark. (thats long run savings i guess, or handier when u receive higher volume traffic perhaps?)
As an example PHP still powers something like 75% of web sites and I've never once used it professionally. If I didn't know better I might think it dead.
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.
>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.
> 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.
riclib, should that be 3 lines?