Where Does Go Actually Win Over Node.js? A Deep Dive into the Performance “Rashomon”

Test Background and Environment

Benchmark compares a Go rewrite of the open‑source reverse‑shell project (GitHub PR https://github.com/lukechilds/reverse-shell/pull/38) with its original Node.js implementation. Tests run on an Apple M4 Max chip and measure HTTP response time (cold and warm), memory usage, CPU consumption, and distribution size.

Execution Time – Cold vs Warm Paths

Cold start (uncached)

Go binaries start faster because they are compiled to native code and have no JIT warm‑up. P50, P90 and P99 latencies for the first request are lower than Node.js.

Warm path (cached)

After V8’s TurboFan JIT compiles hot code, Node.js latency narrows the gap and can be slightly faster under light load.

Memory Footprint

Under identical concurrency, Go uses less than 20 % of the memory consumed by Node.js (approximately one‑fifth). The benchmark marks Memory “Winner” as Go.

Value types and tight struct alignment in Go.

Escape analysis places short‑lived variables on the stack, avoiding heap allocation and GC (see escape analysis article https://mp.weixin.qq.com/s?__biz=MzIyNzM0MDk0Mg==∣=2247488771&idx=1&sn=8ab8754faa36a62cc46fcdf087c3c3b4&scene=21#wechat_redirect).

Goroutine stacks start at 2 KB, far smaller than Node.js async context trees.

Distribution Size and Deployment

Node.js requires the node_modules directory and a runtime, leading to large Docker images. Go produces a single static binary (often a few tens of megabytes) that can be built on scratch, resulting in minimal images and instant start‑up.

Conclusion and Trade‑offs

Go does not universally beat Node.js in raw execution speed; warm‑path latency can be comparable or better for Node.js. Go wins on engineering dimensions: lower memory usage, faster cold starts, and minimal deployment artifacts. Choice depends on whether the bottleneck is cold‑start latency, memory cost, or deployment complexity.