I'm the author, this is my attempt at laughing at my own code.

Can’t wait to play with it. Great design!

Author here. Ask me any questions

the website is just using go standard library and templ. the voice is grok tts. the images are generate by nano banana from prompts written by claude, according to styles. it is all generated by a program called lg: https://yagnipedia.com/wiki/lg

the blog pages are markdown on disk, generated dynamically for each request, cached by cloudflare.

The colored functions point is fair, I was imprecise. My real argument is about the human cost of the compiler fighting AI-generated code, not about async semantics.

Right… but what I'm saying is that for the most part if the compiler pushes back on your LLM-generated code it's because that code is wrong. In the LLM world these are known as ‘guardrails’ and they're great because they a) provide some level of automated verification of the generated code and b) provide actionable feedback to the model to fix the code, where otherwise a human would have to notice the bug and enter the loop. The compiler pushing back on things early is a big positive for vibe coding.

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.

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.

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?)

Fair comment. In my production code I always separate out the css and embed it in the go binary as files that can be cached. Having it in embedded into the page was really useful to iterate behind cloudflare and not worry about css caching but is a terrible practice.

Counterpoint, inlining CSS / JS used to be an optimization in early website optimizers, because fetching multiple files incurred more HTTP overhead, and (...I think) compression was more efficient working on a single file vs three.

I don't think these arguments hold up anymore with http 2/3, but still, it used to be an optimization.

You also have AI write your HN comments.

Here's why!

Would you mind showing us the Go bits of this website?

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

Yes, this is the serious (?) front end to a satirical website.

Okay ... here is that code:

    import net/http

    func main() {
      http.ListenAndServe(":8080",http.FileServer(http.Dir(".")))
    }

Oh and in python: "python3 -m http.server" ...

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.

Obscure? That is just false

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.

Software Engineering is the discipline that, in 1968, looked at the smoldering wreckage of every software project ever attempted and concluded that what it really needed was not better practices, better tools, or better understanding, but a better name. Specifically, someone else’s name. Specifically, the name of people who build bridges.

It has spent the subsequent fifty-eight years proving the metaphor wrong in every measurable way, while simultaneously insisting on keeping it....

I've been building AI applications in Go since August 2024 — before "vibe coding" had a name. After 18 months of AI-assisted development on a Fortune 100 project, the argument for Go isn't performance or deployment anymore. It's the compiler.

When the machine writes 90% of the code, Go gives you five layers between the AI and production: compiler, type system, explicit errors, enforced simplicity, and the human. JavaScript gives you one: the human. And good luck.

The machine proposed a wrapper type last Tuesday. `go build` rejected it on line 47. I said five words: "why do we keep both around?" The wrapper died. In JavaScript, it would have compiled (nothing compiles in JavaScript), passed all tests, shipped to production, and coexisted with the original type for six months until someone proposed a `UnifiedStoreInterface` to bridge the gap.

TypeScript helps — but it's a type system that asks permission. `// @ts-ignore` exists. `strict: false` exists. `any` exists. Go has one mode. There is no `go build --please-actually-check-the-types`.

The machine can generate complexity faster than it can recognise it's unnecessary. Go is the language where the human can still recognise it.

Author here. Yagnipedia is a personal encyclopedia I've been writing — humorous entries on tech concepts, tools, and practices, written in the voice of someone who's spent 20 years building software and has opinions about most of it.

The Boring Technology entry started as a love letter to Dan McKinley's original talk, filtered through the experience of choosing Go, HTMX, and server-rendered HTML for a product in 2026 while everyone around me reaches for React and microservices. The boring choice is almost never the exciting one. It's almost always the right one.

Happy to talk about any of it.