Concurrent TCP server: Go goroutines vs Rust std::thread

WHAT THIS TESTS Whether you can wire up a concurrent TCP server using only standard library primitives in both languages and understand the per-connection concurrency cost.

A GOOD ANSWER COVERS In Go, net.Listen("tcp", addr) returns a Listener; you loop calling ln.Accept, and for each accepted net.Conn you write go handleConn(conn). The goroutine is cheap, starts with a small growable stack, and is multiplexed by the runtime onto OS threads, so spawning one per connection scales to many thousands. In Rust, std::net::TcpListener::bind gives a listener whose incoming iterator yields each TcpStream; for every stream you call thread::spawn(move || handle(stream)), using move so the closure takes ownership of the socket across the thread boundary. Because these are real OS threads, each carries a full stack and kernel scheduling cost.

COMMON WRONG ANSWERS Assuming Rust std threads are as cheap as goroutines and spawning one per connection unbounded; that exhausts memory under load. Forgetting move, which fails the borrow checker. Forgetting to handle the Result from Accept or from reading the stream.

LIKELY FOLLOW-UPS How would you bound concurrency? In Go via a semaphore channel or worker pool; in Rust via a thread pool such as rayon or a custom pool, or by moving to async with Tokio. How do you shut down gracefully and drain in-flight connections?

ONE CONCRETE EXAMPLE Go: ln, _ := net.Listen("tcp", ":8080"); for { conn, _ := ln.Accept(); go handle(conn) }. Rust: let l = TcpListener::bind("0.0.0.0:8080")?; for s in l.incoming() { let s = s?; thread::spawn(move || handle(s)); }. Both accept-and-dispatch, but the Go version tolerates far higher connection counts because goroutines are lightweight while the Rust version pays an OS-thread price per client.