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 our community's equivalent of "where's my flying car?" is "where's my higher-level language?"

Ηelicopters are flying cars and they are everywhere for you to use. But some people prefer to use a bicycle to commute to work, rather than an helicopter. I'd even say that most people would prefer to take a bicycle every day than an helicopter.

The same thing with lower level languages. Sometimes you do not want to be burdened by the limitations of a "high-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.

> Sometimes you do not want to be burdened by the limitations of a "high-level" language.

I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

Who's the "we" who are "stuck"? The vast majority of programmers don't use low-level languages for writing applications even today, but there is a big niche of domains where close to perfect control is needed and that's the domain low level languages like C, C++, Ada, Rust and Zig try to address. I wouldn't (and don't) write "ordinary" applications in those languages, but I don't think the domains they target will ever go away or become less important.

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.

> The vast majority of programmers don't use low-level languages for writing applications

I work in a multi-million-line codebase, a significant majority of which is very far from that "need perfect control" domain but is written in a what I'd call a mid-level language - a high-abstraction dialect of C++. So I'd say GP is correct, that too many people are stuck writing code in the wrong language for the task at hand. The need for languages like Zig to improve the lower-level experience (which, as you say, is not going away) and the need for higher-level languages for more common types of programs are not in conflict. They're complementary. It's the mid-level languages that need to DIAF, because they're not really suited for either and pretending to be more general than they are only encourages people to make choices that hurt them.

I totally agree, and I think that C++ is exactly this "wrong kind of language," and Rust follows in its footsteps, but I'm sure others disagree. For example, for decades Microsoft has shown an attraction to this kind of languages (they love C++, C# is going down that path, and they're showing interest in Rust), so it might ultimately be a matter of taste -- a personal aesthetic preference -- unless somebody is ever able to make some empirical observations that show an objective benefit to one approach over another.

Counterpoint: As long as CPU architectures don't radically change, high-level languages which are too far removed from how CPUs and memory currently work don't make a lot of sense as long as performance (or rather energy efficiency) is a concern. And this should be a much bigger concern than the current status quo. The "free lunch" is long over, we cannot rely on the hardware designers anymore to fix our inefficient high-level code.

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.

For me the way to go are languages that go all the way, C++, Ada, Object Pascal, even .NET and Java could fit into it, if the low level story ever gets straight. Currently AOT like .NET Native seems on the right path to achieve it.

Burroughs, Mesa, Modula, Oberon, Interlisp-D,... were on the right path, but in technology not always the best ideas win.

>STL-heavy C++17 and beyond is, of course, the salient example. I've seen "clever" code in that style, but never great code.

Maybe the authors of that code just had different priorities, such as maximising compilation time.

Hah! Yeah, that does seem sometimes like it must have been a deliberate goal, doesn't it? Got a good laugh out of that. The number of cycles wasted by C++ compilers fumbling toward solutions that would have been obvious in a better language (thousands of server-years per day where I work) is a legitimate ecological concern.

There are situations where precise control over what the machine is doing is very important and a few of the problems that we experience in high-level contexts are caused by the inadequacy of our lower level tools.

Give it a few years and everybody is going to benefit from better implemented "lower-level" applications, thanks to Zig and other languages attempting to do the same.

> I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

I see a huge load of people suffering from those burdens. Higher-level languages tend to be less efficient and less optimal. Yes, they take a burden from the programmer and move that burden onto the end user.

So the programmer is having the easy life, while every user now waits a second longer for the program startup, a second longer for opening the file dialog, and so on. Doesn't sound much, but if you think about it: Worst case is: 1 programmer shaved off two weeks of work on an app that is used by every person on the planet. 7 billion users lost 1 second. In total, humanity lost roughly 200 years of productive time when every person starts the app exactly once.

Modern computers are incredibly fast and we as programmers use that brutal power to be more lazy than before instead of leveraging that power to all of the users of our tools. We could have systems that go from clicking the power button to being readily available for use in less than seconds. Think about this when you chose a high level language that exchanges programmer convenience for runtime cost and think about if it other peoples time is worth your lazyness.

</rant>

disclaimer: don't take it personally, i'm just frustrated about imperformant software

Frankly I find HN more of an impediment to rapid development than C++ compile times.

There are literally 100s of high level languages, for every imaginable programming paradigm. If you want to write fast code where you control memory and don't use a garbage collector, C, C++, and Rust are your only options. It's nice to see new additions to the list.

Ada, D, Pascal/Delphi, and yes, Fortran, are all still options.

I think Zig has the potential to be the best of them, fwiw.

I know personally I'd spend a lot less time on HN if C++ compiled quickly enough that I didn't have time to context switch to something else while waiting for it to compile.

Thanks for writing this.

How is C# similar to C++ in that regard? It's a much higher-level language.