Interview with Zig language creator Andrew Kelley [video]

I hope that we're not stuck writing piles of low-level code for all eternity. We don't need more than a few pages of each low-level language, and while I do really like Zig's qualities compared to C, I'd still like to minimize the amount of Zig or C total that has to be written.

I think that our community's equivalent of "where's my flying car?" is "where's my higher-level language?"

I think that's a valid point that needs to be made in this conversation, and it's super-sad that somebody downvoted you for it.

I've spent much of my career writing low-level code in low-level languages because I had to, usually in C and usually because I was in resource-constrained environments where tight control over CPU and memory footprints was necessary. There's absolutely room for languages that improve programmers' lives in that kind of environment while remaining suitable to that purpose. I'd put Zig in that category, and I find much to admire in it.

However, outside that domain, once you have even a little freedom from those constraints, it makes no sense to use a language designed around them. When even something as simple as manipulating a few strings or updating objects in a map/hash/dictionary requires careful attention to avoid memory leaks or excessive copying, and your code is doing those things a lot, you're using the wrong language. A language that "protects" you by guiding you toward adding the right boilerplate in the right places honestly isn't much of a help. Most code should be written in a truly higher level language, where things like circular references don't require much discussion except by the language implementors. The problem of how to do that without going full-GC and having to deal with pauses is where people should focus their attention, not more languages that just change which ceremony you must adhere to.

It'd argue that the constraints of writing lower-level code can actually lead to producing better code. For instance, idiomatic C, Rust and Zig is to pass a buffer into some function, that it then fills, and the caller handles the output. This leads to having more pure, side-effect free functions, compared to the approach some higher-level languages will take of having the function allocate some stuff in its body, process it, maybe do some IO, and pass it to another function. They encourage "imperative shell, functional core", because of how difficult it is to manage memory/ownership if every random function is allocating promiscuously.

Low-level languages encourage the use of clean ownership patterns, which ultimately leads to cleaner design.

I have a lot of sympathy for that position. The thing that drives me nuts about the codebase I work in now is that it has idioms that involve "promiscuous" memory allocation and then more idioms to fix/cover it up. I'm fine with languages that require completely manual memory allocation (spent most of my career in C). I'm also fine with languages that totally take that burden away. There are tradeoffs either way, but I've seen great code in both of those styles. What I'm not fine with is languages that solve half of the problem and force programmers to learn the brain-dead rules of that half-solution to do their part. STL-heavy C++17 and beyond is, of course, the salient example. I've seen "clever" code in that style, but never great code.