Why I Rewrote My Side Project in Go

The Problem

GoChat started as a Node.js/Socket.io application. At 200 concurrent WebSocket connections, the server was pegging at 60% CPU. By 500 connections, response latency exceeded 2 seconds and the event loop was visibly choking. The broadcast loop — iterating over 500 active socket connections — was CPU-bound work in a single-threaded environment.

Why Go, Specifically?

• Goroutines start at 2KB stack vs 1MB thread — comfortably 100k concurrent goroutines on a single VPS
• Built-in race detector: go test -race catches data races before production
• net/http is production-ready with no framework tax — no Express, no Fastify
• Single static binary with zero runtime dependencies — Docker images are 15MB
• Explicit error handling forces thinking about failure modes at every call site

“

“Concurrency is not parallelism. Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.”

— Rob Pike

The Migration

The rewrite took 6 weeks part-time. I kept the same WebSocket protocol so existing browser clients needed zero changes — only the server changed. The most time-consuming part was not the code; it was the mental model shift from callbacks to goroutines, and from shared mutable state to channel-based communication.

The Results

Six weeks later, the Go server was running in production on the same $6/month Hetzner VPS, the same Redis instance, and the same PostgreSQL database.

Would I recommend rewriting everything in Go? No — measure your bottleneck first. But for any system with long-lived connections and high concurrency requirements, Go should be your first choice. The go-ws-hub library packages the Hub pattern from this rewrite into a reusable, tested library.