b.
All writing
•1 min read#go#engineering

Why I reach for Go on side projects now

After a year of building toy projects in Go, I have opinions. Here's why I keep coming back to it — and where it still loses to TypeScript.

I used to default to TypeScript for everything. Frontend, backend, scripts, glue code. The pitch was simple: one language, no context switch, more time shipping.

Then I built Shrinkr in Go and something clicked.

The boring case

Most side projects are some combination of HTTP server, database, and async work. Go's standard library handles two of those three out of the box — and the third is github.com/jackc/pgx/v5, which is roughly the Postgres driver, period.

http.HandleFunc("/healthz", func(w http.ResponseWriter, _ *http.Request) {
    w.WriteHeader(http.StatusOK)
})
log.Fatal(http.ListenAndServe(":3000", nil))

Two lines. No framework. No npm audit fix. The boring stuff just works.

The honest case

  • Concurrency primitives are first-class. Goroutines and channels make a lot of "I'd need a queue here" problems disappear into a 4-line worker pool.
  • Compile times feel like an interpreted language. go run is the only thing fast enough that I don't notice it.
  • Predictable performance. No surprise V8 deopts, no for-of vs forEach micro-optimizations. The fastest readable code is usually the fastest code, full stop.

Where it still loses

For anything that's mostly shaping data for a UI, TypeScript wins. The DX of Zod + tRPC + a typed React form is genuinely incredible, and pretending Go matches it is dishonest.

So my heuristic now: if the work is "be a fast, predictable pipe," reach for Go. If the work is "render a complicated form people will use," reach for TypeScript. Most projects are some blend, and that's fine — Go and TypeScript talk over JSON like adults.