TCP Listeners: Go vs Rust
Go spins up TCP listeners and handles connections with lightweight goroutines—1 million costs ~500MB—but GC pauses introduce 2-5ms latency. Rust trades boilerplate for zero-cost safety and consistent sub-100µs response times without garbage collection.
Why it exists
Network services need an entry point that waits for incoming TCP connections and dispatches them to handlers efficiently. The source compares how Go and Rust solve this fundamental systems problem, revealing a trade-off between developer velocity and runtime predictability.
The mental model
Think of a TCP listener as a doorman. Go hires thousands of lightweight goroutines as doormen that are cheap to spawn and easy to manage, but occasionally the building management runs a garbage collection sweep that freezes the lobby for milliseconds. Rust trains an elite staff where the compiler proves ahead of time that no two doormen will fight over the same guest list, eliminating both data races and garbage collection pauses entirely.
How it works
Go provides batteries-included networking. The source shows a working HTTP server in 12 lines using http.ListenAndServe on port 8080. Underneath, Go's runtime spins up goroutines per connection and the source notes 1 million goroutines consume approximately 500MB RAM. This model prioritizes fast development cycles and immediate execution with go run. Rust takes a different path. The source highlights Actix as a web framework and demonstrates fearless concurrency using Arc and thread spawning. Rust's compiler enforces ownership rules so that shared state across connection handlers cannot create data races. There is no garbage collector, which means memory management is deterministic and latency remains consistent.
When to use it
Choose Go when you need to ship fast. The source emphasizes Go's minimal syntax, fast compilation, and lightweight concurrency as ideal for cloud infrastructure like Docker and Kubernetes. It fits scenarios where a 2-5ms GC pause every few seconds is acceptable. Choose Rust when tail latency matters. The source cites p99 latency under 100 microseconds with no GC pauses, making it suitable for high-performance proxies, edge networks, and systems where predictable response times outweigh initial development speed.
When not to use it
Do not use Go if your workload cannot tolerate stop-the-world garbage collection pauses in the 2-5ms range, such as high-frequency trading or real-time streaming where every microsecond counts. Do not use Rust if your team needs to iterate rapidly and cannot absorb a 2-3 month learning curve or 5-10x slower compilation times that drag on the development loop.
One canonical example
The source contrasts Go's 12-line HTTP server against Rust's compile-time safety guarantees. In Go, you write http.HandleFunc and http.ListenAndServe, launch immediately with go run, and let the runtime schedule goroutines. In Rust, you might use Actix or standard networking primitives with Arc clones and thread handles, trading a steeper learning curve for zero-cost abstractions and latency consistency.
Interview question
Which factor most directly explains Rust's consistent sub-100µs latency compared to Go's 2-5ms pauses?
- a.Rust optimizes developer velocity with faster compilation and minimal syntax
- b.Rust uses Arc clones and ownership rules to share state without data races
- c.Rust handles connections with lighter-weight threads than Go's goroutines
- d.Rust eliminates garbage collection, avoiding stop-the-world memory management pausesCorrect
Why? this is the answer
Rust's deterministic memory management without a garbage collector removes the 2-5ms stop-the-world pauses that cause Go's latency spikes. While Arc and ownership rules prevent data races, they are not the primary driver of the sub-100µs tail latency.
Just read this? Test yourself on what you have been reading.
Read the original → cloudbridge-research.ru
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on go — each one lists the topics its interview covers.
See open roles