Networking¶
Why it matters¶
Almost every program you'll ship eventually talks to something over a network. The vocabulary (sockets, TCP, HTTP, TLS, gRPC) is the same everywhere; the libraries and idioms differ per language. This page maps each path's take so you can read across runtimes.
The lens, per path¶
Linux kernel - the substrate¶
Month 4 - Networking. Every path's networking ultimately sits on Linux's. Sockets API (socket, bind, listen, accept, connect, send, recv), the TCP/IP stack, netfilter/iptables, XDP, epoll.
What's unique here: the platform. Every higher-level networking primitive (Go's net.Conn, Java's Socket, Python's asyncio transports, Rust's tokio::net) bottoms out in these syscalls. Understanding the kernel makes "why is my socket EAGAIN" diagnosable.
Go - net + net/http in the standard library¶
Month 5 - Production / Distributed. The net package is the substrate; net/http is a production-grade HTTP server in the standard library. http.Handler is the central interface - write one method, you're an HTTP service.
What's unique here: the standard library covers ~80% of production HTTP needs. Connection pooling, HTTP/2, TLS, graceful shutdown all built in. The goroutine-per-request model under the runtime scheduler scales to tens of thousands of connections per process.
Java - java.net.http + Netty + virtual threads¶
Month 5 - Production / Distributed. The modern Java HTTP client (java.net.http.HttpClient, since 11) handles HTTP/1.1, HTTP/2, sync, async. For servers, the JDK ships a tiny one; production uses Tomcat/Jetty/Undertow under Spring Boot, or Netty directly for low-level work.
What's unique here: the Loom-era pivot. Virtual threads (Month 4) make blocking I/O cheap again - spring.threads.virtual.enabled=true lets a 2024+ Spring Boot service handle thousands of concurrent requests with thread-per-request semantics and no reactive complexity. Reactive (Netty + Project Reactor) remains for backpressure-heavy streaming.
Rust - Tokio + hyper + reqwest¶
Month 3 - Concurrency & Async, then Month 5 - Production Architecture. The async story is built on Tokio (executor + reactor). tokio::net::TcpStream/TcpListener are the low-level types. hyper is the HTTP implementation; reqwest wraps it for client work; axum is the popular server framework.
What's unique here: zero-cost futures + Tokio's epoll/kqueue/io_uring integration give Rust the best raw I/O throughput of any garbage-collected-free language. The cost: async/await adds learning curve on top of ownership.
Python - sockets + asyncio + httpx + FastAPI¶
Month 4 - Concurrency & Parallelism. Sync socket for low-level; asyncio for high-concurrency I/O; httpx for modern HTTP (sync + async); FastAPI for async-native HTTP servers; requests for sync HTTP (still the most popular library by far).
What's unique here: Python's sweet spot is "glue layer to other systems," and the HTTP-client story is excellent. The server story is fragmented (Flask/Django/FastAPI/Starlette/etc.); pick by team needs.
gRPC - the cross-language modern RPC¶
Covered in all four language capstones. Protocol buffers as the IDL, generated stubs per language, HTTP/2 as transport. Streaming RPCs, deadlines, interceptors for cross-cutting concerns (auth, tracing, retries).
Why it matters across paths: if your services are in 3 languages, gRPC gives you a typed contract everyone can implement. The contrast with REST: schema-first (vs schema-last), streaming-native (vs polling), binary (vs JSON).
The IO-multiplexing story¶
Underlying all the async runtimes:
| Mechanism | Used by |
|---|---|
epoll (Linux) |
Go's netpoller, Tokio, asyncio's default selector, Netty |
kqueue (BSD/macOS) |
Same runtimes, on Mac/BSD |
| IOCP (Windows) | Tokio, asyncio, .NET runtime |
io_uring (Linux 5.1+) |
Tokio (opt-in), some Java NIO experiments, libuv |
Every "high-performance async runtime" you'll meet uses one of these. The differences (epoll's edge vs level triggering, io_uring's submission queue model) matter for the runtime authors; rarely for app authors.
The contrasts that teach¶
| Aspect | Go | Java (post-Loom) | Rust (Tokio) | Python | Kernel |
|---|---|---|---|---|---|
| Sync I/O model | blocking, on goroutines | blocking, on virtual threads | async (no sync ergonomics) | blocking, on threads | blocking, on processes/threads |
| HTTP server in stdlib? | yes (net/http) |
yes (HttpServer) but use a framework |
no - hyper/axum |
basic (http.server); production-grade via Starlette/FastAPI |
no, but nginx/apache ubiquitous |
| TLS in stdlib? | yes (crypto/tls) |
yes (javax.net.ssl) |
no - rustls or native-tls |
yes (ssl) |
yes (kernel TLS / OpenSSL) |
| Default concurrency unit per connection | goroutine | virtual thread | future (task on executor) | coroutine (asyncio) or thread | thread or process |
| gRPC stdlib? | no - google.golang.org/grpc |
no - io.grpc:grpc-* |
no - tonic |
no - grpcio |
|
| Backpressure primitive | channels | reactive streams (Reactor) | Sink/Stream traits |
asyncio queues / aiohttp flow control |
TCP windows, kernel buffer limits |
The single most clarifying cross-read: Go's net/http.Handler + Tokio's axum::handler + Java Spring's @RestController. Three different syntaxes for the same shape - "given a request, produce a response."
What to read first¶
- You build backend services → Go Month 5 or Java Month 5 + 4. The post-Loom Spring Boot story is the easiest production-grade setup.
- You want maximum throughput / minimum latency → Rust Month 3 + 5. Tokio + hyper + axum is the modern stack.
- You write Python at scale → Python Month 4, then FastAPI's docs. Async Python's productivity has caught up.
- You operate Linux services → Linux Month 4.
tcpdump/ss/netstatare diagnostic tools you'll use weekly. - You design APIs spanning languages → gRPC docs + each language's gRPC chapter. Schema-first beats schema-last for cross-team work.