But beneath the syntax sugar lies one of the foundational design forks in programming language theory: ownership during iteration.

When you write a loop, the language runtime has to make a critical decision about the data you are accessing. It must decide whether to give you a copy of the data, a reference to the data, or something in between. This isn’t just an implementation detail; it defines the performance characteristics, safety guarantees, and bug classes of your entire application.

In this post, I want to dissect these iteration models and explore why the “same” loop compiles down to very different contract with memory.

Omni-present syntax, Divergent semantics

Let’s look at the hidden question every loop answers: What exactly is the loop variable?

Is it a copy? A reference? A borrow?

1. Value Iteration (Go)

In Go, iterating over a slice with range defaults to providing a copy of the value.

for _, v := range slice {
    v.field = "changed" // Modifies the copy, not the original
}

This model defaults to safety via isolation. Because v is a copy, you cannot accidentally mutate the underlying collection or cause spooky action-at-a-distance. The memory model is simple: iteration creates new stack-allocated values.

The Trade-off:

• Pros: It eliminates an entire class of aliasing bugs.
• Cons: It incurs a hidden performance penalty. If your slice contains large structs, every iteration triggers a memcpy, which can silently kill throughput in hot paths.

2. Reference Iteration (Python, JavaScript, Java)

Contrast this with the model favored by high-level managed languages. In Python or JavaScript, the loop variable is a reference (or pointer) to the object in the heap.

for user in users:
    user.name = "X" # Modifies the original object

Here, the language prioritizes ergonomics and zero-copy. You are working directly with the data.

The Trade-off:

• Pros: It’s performant by default regarding memory bandwidth (no copying).
• Cons: It introduces implicit aliasing. A mutation inside a loop updates the state “globally” for anyone holding a reference to that object. This creates the classic concurrency nightmare: if another thread touches users while you are iterating, you have a race condition.

3. Borrowed Iteration (Rust)

Rust takes a third path, exposing the memory model directly in the syntax. It forces you to choose the contract you want with the data using its ownership system.

for user in &users {}     // Immutable borrow: Read-only access
for user in &mut users {} // Mutable borrow: Exclusive write access
for user in users {}      // Move: Transfer ownership (consume collection)

Ideally, this is the “correct” solution from a systems perspective. It provides the zero-cost benefits of Reference Iteration without the safety hazards.

However, it introduces friction. The borrow checker will strictly enforce that you cannot mutate the collection structure (like pushing/popping) while iterating over it—a common source of iterator invalidation bugs in C++.

The Universal Baseline: Index Iteration

When abstractions fail, every language allows you to fall back to the raw, C-style access pattern:

for i := 0; i < len(slice); i++ {
    slice[i] = mutate(slice[i])
}

This is Index Iteration. It is the ultimate “trust me” mode. It bypasses iterator protocols entirely, giving you precise control over memory access at the cost of safety (off-by-one errors) and readability.

Conclusion

The loop isn’t just a control flow structure; it’s a window into the language’s philosophy.

Next time you type for, pause and ask: Who owns this data? The answer might save you from a production bug down the line.

const express = require("express");
const app = express();
const port = 3000;

app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`);
});

This snippet starts an HTTP server on port 3000 and registers a handler for the / route. It is popular for a reason: it is simple, expressive, and hides a large amount of complexity behind a clean API.

But underneath this simplicity, a web server is still just a program that reads and writes bytes over a network socket. Express is not “magic” — it is a carefully engineered system that sits on top of TCP and implements the HTTP protocol, routing, middleware, parsing, and response handling for you.

In this article, we will peel away those abstractions and build a very small HTTP router directly on top of a raw TCP stream.

To be precise: we are not “routing TCP.” Routing is an HTTP-level concept. TCP only provides a stream of bytes. Our job will be to interpret those bytes as an HTTP request and then choose a handler based on the request’s method and path.

What Really Happens Inside a Web Server?

At a high level, every HTTP server follows this pipeline:

Frameworks like Express implement this entire pipeline for you. We will implement a minimal version of the same idea ourselves.

The goal is not to replace Express — it is to understand what it is actually doing under the hood.

A Minimal TCP-Based HTTP Router in Rust

A TCP connection gives us nothing more than a stream of bytes. If we want routing, we must:

Here is a minimal teaching implementation:

fn handle_client(mut stream: TcpStream) { let mut buffer = [0; 1024];

    match stream.read(&mut buffer) {
        Ok(size) => {
            let request = String::from_utf8_lossy(&buffer[..size]);

            let (status_line, content) = match &*request {
                r if r.starts_with("POST /users") => handle_post_request(r),
                r if r.starts_with("GET /users/") => handle_get_request(r),
                r if r.starts_with("GET /users") => handle_get_all_request(r),
                r if r.starts_with("DELETE /users/") => handle_delete_request(r),
                _ => (NOT_FOUND.to_string(), "Not Found".to_string()),
            };

            let response = format!("{}{}", status_line, content);

            if let Err(e) = stream.write_all(response.as_bytes()) {
                eprintln!("Failed to send response: {}", e);
            }
        }
        Err(e) => eprintln!("Error reading from stream: {}", e),
    }

}

Let’s break down exactly what is happening in this code.

1. Reading from the Socket

let mut buffer = [0; 1024];
match stream.read(&mut buffer) { ... }

We create a fixed-size buffer of 1024 bytes and try to read data from the TcpStream. This is where we get the raw bytes sent by the client (your browser).

2. Converting Bytes to String

let request = String::from_utf8_lossy(&buffer[..size]);

The browser sends bytes, but we need text to make routing decisions. String::from_utf8_lossy converts the raw bytes into a Rust String. If there are invalid UTF-8 sequences, it replaces them with instead of crashing.

3. The Routing Logic (Pattern Matching)

let (status_line, content) = match &*request {
    r if r.starts_with("POST /users") => handle_post_request(r),
    r if r.starts_with("GET /users/") => handle_get_request(r),
    r if r.starts_with("GET /users") => handle_get_all_request(r),
    r if r.starts_with("DELETE /users/") => handle_delete_request(r),
    _ => (NOT_FOUND.to_string(), "Not Found".to_string()),
};

This match block is the core Router. It inspects the request string to see if it starts with a specific method and path combo (like "GET /users").

• If it matches, it delegates to a specific handler function (e.g., handle_get_request).
• If no patterns match, it defaults to the _ case, returning a 404 Not Found.

4. Sending the Response

let response = format!("{}{}", status_line, content);
stream.write_all(response.as_bytes())

Finally, we take the result from the handler (the status line and the content), combine them into a single HTTP response string, and write the bytes back to the socket.

[!NOTE] This Is a Teaching Implementation

This code is intentionally naive:

• HTTP requests can be larger than 1024 bytes.
• read() is not guaranteed to return the full request in one go.
• Real servers must handle partial reads, buffering, persistent connections, and full HTTP parsing.
• A real router parses the request line and headers properly instead of using simple string prefix matching.

Despite these limitations, this implementation exposes the core idea: routing is just structured decision-making over bytes read from a TCP socket.