Why I Vibe in Go, Not Rust or Python
lifelog.my
lifelog.my
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.
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?)
I don't think these arguments hold up anymore with http 2/3, but still, it used to be an optimization.
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).
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.
import net/http
func main() {
http.ListenAndServe(":8080",http.FileServer(http.Dir(".")))
}
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.
> 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.
In this particular case maybe Rust isn't the right choice because (idiomatic) Rust is designed for the case where you care about your memory management, and for your blog you probably don't. But that's a comment on the suitability of Rust for blogs, not a comment on the suitability of Rust for vibe coding.
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’s also great that you acknowledge the hard work of the humans that got Go into the great state it’s in.
Your blog post needs heavy edits to let your voice speak through over the AI you started from: for example, your headings say “The X.”, “The Y.” Please edit away the AI-isms before publishing. Leaving them in shows a lack of care, and I’m sure that is not the impression you wanted.
riclib, should that be 3 lines?
can you share your prompt go make the website , what is the stack
the blog pages are markdown on disk, generated dynamically for each request, cached by cloudflare.
>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 mean it is there, and it works.
The argument is that developers will avoid using things if they don't have to, especially if they're not used to it. But this isn't every developer nor an universal truth, just a jab at things.
Clojure is the most token efficient of the major languages. It's a pleasure to work in. The sample code base that Claude knows skews toward higher quality code than the large volumes of middling JS or Python (this is not about the language but about what gets shared in the open for training data).
You want binaries... Babashka.
CLI... sure.
Access to the entire Java ecosystem... also yes.
The one other virtue is that when I use Clojure to demonstrate some feature, no one at work is tempted to deploy it as is until they rewrite it for Node.