Comment by pjmlp

"modern: relating to the present or recent times as opposed to the remote past". I agree it's not a useful concept here but I didn't bring it up. Specifically, I don't think there's any consideration that had gone into the design of D, C#, or Rust that escaped Zig's designer. He just consciously made different choices based on the data available and his own judgment.

> Not really modern, it is Object Pascal/Modula-2 repackaged in C like syntax.

That's your opinion, but I couldn't disagree more. It places partial evaluation as its biggest focus more so than any other language in history, and is also extraordinarily focused on tooling. There isn't any piece of information nor any technique that was known to the designers of those older languages and wasn't known to Zig's designer. In some situations, he intentionally chose different tradeoffs on which there is no consensus. It's strange to insist that there is some consensus when many disagree.

I have been doing low-level programming (in C, C++, and Ada in the 90s) for almost 30 years, and over that time I have not seen a low-level language that's as revolutionary in its approach to low-level programming as Zig. I don't know if it's good, but I find its design revolutionary. You certainly don't have to agree with my assessment, but you do need to acknowledge that some people very much see it that way, and don't think it's merely a "repackaged" Pascal-family language in any way.

I guess you could say that you personally don't care about Zig's primary design points and when you ignore them you're left with something that you find similar to other languages, but that's like saying that if you don't care about Rust's borrow- and lifetime checking, it's basically just a mix of C++ and ML. It's perfectly valid to not care about what matters most to some language's designer, and it's perfectly valid to claim that what matters to them most is misguided, but it is not valid to ignore a language's design core when describing it just because you don't care about it.

> Also it is the wrong direction when the whole industry is moving into integrity by default on cyber security legislation.

Again, that is an opinion, but not one I agree with. For one, Rust isn't as safe as other safe languages given its relatively common reliance on unsafe. If spatial and temporal memory safety were the dominating concerns, there wouldn't be a need for Rust, either (and it wouldn't have exposed unsafe). Clearly, everyone recognises that there are other concerns that sometimes dominate, and it's pretty clear that some people, who are no less knowledgeable about the software industry and its direction, prefer Zig. There is no consensus here either way, and I'm not sure there can be one. They are different languages that suit different people/projects' preferences.

Now, I agree that there's definitely more motion toward more correctness - which is great! - and I probably wouldn't write a banking or healthcare system in Zig, but I wouldn't write it in Rust, either. People reach for low level languages precisely when there may be a need to compromise on safety in some way, and Rust and Zig make different compromises, both of which - as far as I can tell - can be reasonable.

> There are several examples around of doing arenas in said languages.

From what I can tell, all of them either don't provide freedom from UAF, or they're not nearly as general as a proper arena.

I know of one safe and general arena design in RTSJ, which immidiately prevents a reference to a non-enclosing arena from being written into an object, but it comes with a runtime cost (which makes sense for hard realtime, where you want to sacrifice performance for worst-case predictability).