my problem with low level languages

intro

Low-level languages have always fascinated me: C, Odin, Zig, C3 and their relatives. They give you the power to manipulate memory directly. Heap or stack, pass by reference or by value: no magic underneath, everything under the programmer’s control.

But coding is only half of the joy of programming. The other half is seeing your work be useful to someone. And that’s where low-level languages keep failing me: I almost never have a real use-case for them.

web and desktop

Need a web server? JavaScript, Java, Python, even PHP will do. A desktop or mobile app? Java, Swift, C#, Dart/Flutter.

The main concern for user-facing applications is the IO layer and fast development iteration, and the heavy lifting is already done in native code you reach through FFI. NumPy wraps C. SQLite sits inside nearly every mobile app. Your Node server hands TLS off to OpenSSL. The low-level work exists; it was just finished years ago, by someone else.

games

Game development isn’t free from this either. Unreal Engine expects C++, but many developers rely on its “drag and drop” Blueprints instead. Clair Obscur: Expedition 33 was built roughly 95% in Blueprints. Unity scripts in C#; Godot in GDScript or C#. In every case an optimized native core does the heavy lifting while the game code sits one comfortable level above it.

Going engine-less is the obvious counter, and I tried it: raylib with Odin. raylib gets a window, input handling and a draw loop on screen in a dozen lines, and Odin is a genuine pleasure to write. But past simple 2D games I found myself rebuilding what an engine gives away for free. Unless you’re a multi-hundred-million-dollar studio, that trade rarely pays.

cli apps

CLI tools looked like the natural home for low-level languages. In practice? A script that organizes my files ends up in bash. A package manager ends up in Go or Python. Even Homebrew is written in Ruby.

The obvious objection: ripgrep, fd, bat, the whole modern CLI renaissance happening in systems languages. Fair. But those tools win because their authors needed performance at a scale I don’t: searching millions of lines, walking enormous directory trees. My CLI ideas are glue: moving files, calling APIs, wrapping other tools. Glue doesn’t need manual memory management; C or Odin a scripting language finishes the job before I’d have picked an allocator.

libraries & embedded

So what’s left? Libraries consumed by higher-level languages, and software for low-resource environments. Real use-cases, just not mine. A library nobody depends on is a tree falling in an empty forest, and I don’t have any embedded hardware problems to solve.

thoughts

So here I am, demotivated. How am I supposed to enjoy building software in these languages when the only use-cases left are libraries nobody will depend on and embedded systems I don’t care about?

I’ll keep the hobby projects going. I’ll keep learning Odin, poking at Zig, reading other people’s C. But I doubt any of it will ever ship to anyone. The coding is there; the usefulness isn’t. And half a joy, it turns out, doesn’t feel like half. It feels like less.