Why I Switched from TypeScript to Go

I spent five years writing TypeScript for a living, and I still reach for it on the frontend without a second thought. But somewhere around the third time I watched a Node service fall over under load that a Go binary would have shrugged off, I stopped defending the status quo and started rewriting.

It was never about the language being "better"

TypeScript's type system is genuinely more expressive than Go's. Conditional types, mapped types, discriminated unions modeled to the byte - Go has nothing like it, and most days it does not need to. What pulled me over was everything wrapped around the language: a single static binary, a runtime that does not need babysitting, and a standard library that ships an HTTP server you would actually run in production.

The operational story is the real pitch

With Node I was always assembling a runtime - which version, which package manager lockfile, which set of native modules that break on the CI image. Go collapses all of that into go build. The artifact is a file. It starts in milliseconds, the memory ceiling is predictable, and goroutines let me write straight-line concurrent code instead of threading callbacks and promise chains through every layer.

What I gave up

The ecosystem is thinner. There is no equivalent to the npm long tail, error handling is verbose in a way that genuinely annoys me on a bad day, and generics arrived late and still feel bolted on. None of that outweighed shipping services that run for months without my attention. If your bottleneck is operational reliability rather than modeling power, Go is worth the discomfort of the first month.