Zig 2024 roadmap

In my background I'm used to manually thinking about and managing lifetimes anyway. For example, using array indices rather than pointers, minimising the total number of allocations, documenting exactly how data is stored and in what order things should be "set up", "used" and "torn down" (in whatever means is appropriate for the language), passing responsibility for allocation towards the caller as much as is practical, and so on. I just don't write code in the first place that does "lots of little allocations and deallocations here there and everywhere"*; I think carefully about every single allocation; so, effectively by necessity, "lifetimes" isn't a very complex topic in my code, with the consequence that Rust's advantages don't really apply to it. (A function that returns a pointer to part of its own stack frame, like your example, is something I learned never to write a long time ago.)

*unless I'm using a high-level language like Python, where allocations happen constantly, but the garbage collector prevents any memory-unsafety troubles at the cost of performance. However, even in Python, I'm still thinking about the "semantics" of setup and teardown in the same way, because although memory management isn't involved in it, you can still run into the same traps with higher-level resources such as files, sockets, threads, processes, async tasks, or the state of a database.

On the other hand, I constantly find myself running into "completely obvious and stupid once you find it" buffer overflows, off-by-one errors, and so on. This is a class of problems that Zig solves immediately with slices. In one particular example, I had a known bug (as in, the effect was known, but not the explanation or the solution) in some C code that lasted for years because, each time the edge case that caused it arose, it would set a byte one beyond the end of a buffer to zero when that byte is usually zero anyway, but then just occasionally that byte isn't supposed to be zero, so something completely unrelated fails long after the code that wrongly sets that byte is done, making it impossible to figure out why. If that was Zig code, using a slice for that buffer would have given me a panic with a relevant stack trace immediately the very first time that write was detected, and I would have been able to fix it straight away. (Even valgrind didn't detect this bug: although it was out of bounds of the array, it was still part of a single memory allocation, hence why instead of causing an immediate crash it corrupted some unrelated behavior later.)

Of course it's not just slices. Zig also brings a bunch of other useful features that C doesn't have: tagged unions, comptime, RLS and its unique approach to error handling, to name a few. The first and last of these are also places where memory safety bugs completely unrelated to lifetimes show up in C over and over again. Rust has some of these features too, but that's irrelevant to the fact that Zig is still far better than C.

Basically my argument is that I feel Zig would solve the vast majority (if not all) of the "extremely hard" bugs I actually run into in practice, and while yes, Rust would not let code with those bugs compile, it would also make it a lot harder to write anything in the first place, but wouldn't bring me any further benefits beyond what I'd get from Zig. This is what I meant by "Zig is pragmatic." (The caveat of course being that I've only experimented a little so far with Zig, and almost not at all with Rust, so I can't exactly speak from experience with either language.)

So, yes, I was wrong to make such a sweeping generalisation with my original comment. But I hope I have at least demonstrated that the dismissive, rhetorical question of "Why are we, as an industry, pouring resources into non-memory-safe languages [like Zig]?" is equally misplaced :)