The Value of Programming Languages That Don't Hide the Details

When most people start programming, they're drawn to languages that make things easy. Python, JavaScript, and other high-level languages abstract away the messy details of memory management, system calls, and hardware interaction. This abstraction is powerful—it lets beginners create useful programs quickly without getting bogged down in implementation details.

But there's significant value in languages that force you to confront these details. Languages like Rust, C, and Zig don't just make you a better programmer in those specific languages—they deepen your understanding of how computers actually work. This understanding makes you more effective in every language you use, even the high-level ones.

To demonstrate, let’s take a “simple” concept like reading input from the user and storing it in a variable, then demonstrate how it would be done from higher, to lower-level languages. We’ll start with the highest of them all:

Python

name = input("What is your name?\n")
print(name) #Ah, the classic I/O example

To a learner, what could the questions and learning be here? Remember, we aren’t just trying to crank out code, but to actually have an idea of what’s going on:

• Variables and Memory: We have “variables” which hold data.

• Data Types and Memory: We have data types, and strings are simply normal text. A very curious learner could even learn about the other data types from this clue.

• Function Calls: We can call functions with arguments and store the results of those functions in a variable.

• Runtime Environment Python programs can be run by calling the interpreter and with the program (assuming we have Python installed, I’m not going to poke the bear that is Python versioning, dependencies, and installation). This could lead to a discovery on interpreted vs compiled languages.

These aren’t bad, I think the biggest knowledge about computers will come from that little ‘\n’ in the string. Exploring a little on this would lead to knowledge about ASCII, UTF-8, and the representation of text in the computer as bytes. It would probably be too much for a beginner, but it would give them an idea of how text goes to 0s and 1s. There is also a little lesson on interpreters and compilers here, but that would require significant digging.

Javascript/Typescript (Node)

import readline from 'readline/promises';

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
});

const name = await rl.question('What is your name?\n');
  rl.close();

console.log(name);
//Oh, js, so horribly wonderful in your ways

In addition to the previous insights, let’s evaluate what a curious learner could observe from simply exploring this code:

• Input/Output Streams: We see explicit references to the stdin, and stdout. A simple exploration of these would lead to the stdin and stdout file streams in Unix-based environments, and perhaps even file descriptors and the ‘everything is a file’ in Linux systems.

• Processes: Seeing the Process object could trigger a curious person to find out about processes and gain a glimpse of the execution process for modern operating systems. While they may not fully get it, they now have an idea.

• Asynchronous I/O: await and Promises introduce the learner to how computers handle operations that don't complete immediately, and maybe even a question on why it doesn’t just execute in a straightforward manner (like Python). These drive to learning about:

  • Synchronous and asynchronous execution, non-blocking I/O, and maybe concurrency

  • Promises, the Microtask Queue, and the Task Queue in Node, event-driven programming and its benefits.

• Interface Creation and Resource Management: The creation and closing of an interface leads one to question and gain an understanding of resource management, especially for important resources like I/O streams.

• Declaration Keywords (let, const): These don’t explicitly map to deeper concepts, but they teach good practices of controlling mutability.

• Runtime Environment: JS programs are run via a runtime, Node, Bun, Deno, etc. The job of the runtime is to provide V8 (the JS engine) with the extra features to make it a complete language. One could perhaps question what exactly these runtimes provide to the V8 engine, and this would lead to the implementations of async I/O.

Some of these, like Promises and Queues, are JS-related abstractions at first glance, but if a person eventually finds their way to Libuv — the C library that handles asynchronous I/O for Node.js, they’re going to learn a little about I/O in operating systems.

C-Sharp

Console.WriteLine("What is your name?");
string? name = Console.ReadLine();
Console.WriteLine(name); //Surprise!! No public static void Main(string[] args)

The usual suspects of character encoding are here, albeit obscured by the ReadLine and WriteLine, besides those, two important things come up:

• Static Typing and Explicit Types: While type inference is a wonderful feature for productivity, I maintain the view that explicitly writing types improves the learning process, particularly for beginners. Here, a learner could gain their first real idea of memory layout, especially as they explore the reasons for explicitly specifying the types of variables. These include the reservation of specific byte counts for certain variables, and the errors that occur when you try to fit 64 bytes into 32 bytes of memory.

• Nullable Types: They learn that it is possible for a memory location to have an absence of a valid value, further enhancing the view of memory.

• A really curious person would start asking — why do we have to explicitly state nullable types? Are there any particular issues that stem from treating null values as non-null values in programs? This leads to learning about memory protection rules.

• The Common Language Runtime(CLR), Intermediate Language(IL), and JIT: The .NET runtime makes the compilation process more obvious by forcing the learner to explicitly build, and then run the code.

Forcing a user to compile their code allows them to see the generated IL. This allows us our first look into assembly(pseudo-assembly, anyway), instructions, and registers. There is also the potential to learn about Just-In-Time compilation of the CLR if a learner pokes a little further under the hood.

While these concepts do exist in other languages, the difference is that exposing them to the user allows them to immediately poke deeper and gain an idea about what really happens to run the code.

Finally, I/O Is More Abstracted Here than JS. We don’t have anything related to the streams and resource management.

Golang

Sorry, Gophers, but I can’t cover everything, or this article would become too long.

Rust

use std::io;

fn main() {
    println!("What is your name?");
    let mut name = String::new();

    io::stdin()
        .read_line(&mut name)
        .expect("Failed to read line");

    println!("{}", name);
}
//Almost a 1:1 from The Book

To a moderately curious learner, what could be understood about system concepts:

• Explicit Mutability: mut keyword shows variables are immutable by default. Again, control over the mutability of data for all of its benefits.

• Explicit Error Handling: .expect() shows that I/O can fail and forces error handling consideration. This is almost taken for granted in higher languages, and a learner can understand that interacting with the physical devices could lead to a host of errors which one might not think about if they weren’t brought forward. As an example, try asking a database developer if disks are perfect.

• Direct Stream Access: io::stdin() explicitly reveals interaction with OS-level I/O resources. Just like before, this allows for a deeper dive into I/O concepts in an OS, the difference here being that things are a lot more bare than they were in JS.

• Memory Allocation: String::new() shows our first, albeit pseudo-explicit, encounter with the heap and the stack, two of the most important concepts in memory. Though not very explicit, it gives enough of a clue that the curious learner might easily start exploring memory and ask questions like — “why do we need different memory regions?”, “what is the heap?”, etc.

• References & Borrowing: &mut name reveals our first explicit introduction to pointers. Though every language so far has used references under the hood, exposing it front-and-center to the programmer allows them to start gaining deeper ideas of memory layout. They learn we can use the same data in multiple regions by simply using references, along with the benefits and dangers of such an approach.

• Compilers, Executables, and Assembly: Once again, explicitly requiring a build step causes the learner to start exploring the compilation process, but this time, they have a chance to see explore up to the point of assembly instructions, and a little about the execution process of modern CPUs.

Even if you’re comfortable with high-level abstractions, experimenting with one small element in Rust can illuminate a whole world of system behavior that remains hidden in other languages. Most of these are not new, so to say, the difference is that here, they are exposed to the programmer, forcing them to think and learn about them. This does bring extra overhead and difficulty, but this is rewarded by a deeper understanding, and consequently, power over the resources of the system.

Zig

const std = @import("std");

pub fn main() !void {
    var debugAllocator = std.heap.DebugAllocator(.{}).init;
    defer std.debug.assert(debugAllocator.deinit() == .ok);

    const allocator = debugAllocator.allocator();

    const stdout = std.io.getStdOut().writer();
    const stdin = std.io.getStdIn().reader();

    var name = std.ArrayList(u8).init(allocator);
    defer name.deinit();

    try stdout.print("What is your name?\n", .{});
    try stdin.streamUntilDelimiter(name.writer(), '\n', null);

    try stdout.print("{s}\n", .{name.items});
}
//lol, the code block doesn't have support for Zig

NOTE: I really debated whether or not to include heap-allocated ‘growable’ strings or to simply have a very large, stack-allocated ‘static’ string, but since I’ve used ‘growable’ strings for every other example, here we are. To explain simply, a growable string can grow with extra input, whereas a static string is fixed — the only way to add new characters is to create a new one with the new character.

Oh boy, where do we start? If a learner were to look at this code, they’d probably get scared and run away, but what could be learned about system concepts by exploring this:

• Allocators and Memory: Zig makes it explicit to us that when we need to get memory from the heap, we need to declare our intentions to do so; this isn’t quite abstracted for us as in Rust, here, it’s laid bare. While this does add more initial overhead, it prompts the developer to start exploring the stack, heap, dynamic memory, OS syscalls and why we even need to explicitly allocate and free memory.This further strengthens the developer’s understanding of memory structure.

• Cleanup and Leak Detection: The explicit defer calls to clean up memory and the checks for memory leaks are good starting points to learn firsthand the issues that arise from improperly managed memory. At this point, the developer is sufficiently equipped to go really deep on this topic.

• String, Slices, and References: Strings are simply pointers to an array of u8 values. This removes the last bit of abstraction between the high-level ‘string’ concept, and the low-level ‘array of bytes’ idea.

• Direct Access to I/O Streams: Again, by making these things visible, the developer understands what happens when they read or write from I/O outside the program.

• I/O Errors and Error Handling: I/O devices calls — and syscalls, in general — can fail. The developer has to explore and be aware of this.

C and C++

I think you get the point I’m making here, no need to beat a dead horse.

So, there you go. A simple task in multiple languages. I hope you’ve been convinced of my point. Before we go, though, let’s make a few things clear:

So, Just Write Rewrite It In Rust?

No, the answer is no — just no. I make these arguments from the perspective of one who wants to learn more about how computers work, and the one who needs to squeeze everything out of your hardware (you could also go assembly like the guys over at FFMPEG for that, if you want).

But what happens when you’re fine with sacrificing some efficiency for the sake of development speed? What if you need to write a lightweight web server with some logic in a day or two? What happens when you’re a new developer who’s so intimidated by C++ that they want to drop code?

There are a lot of situations out there for which something like Go, Elixir, Haskell, or whatever is just fine. I only ask that after that, you take some time and learn a little bit about what’s really going on; you don’t have to be a low-level whiz who can write asm in their sleep, but knowing what happens with computers will help you write better, more performant code. And, it’ll help you stop seeing your computer as a black box. I also promise you’ll enjoy it.

Talk to me on Twitter