I feel like one thing that wasn't made clear - it's not necessarily the job of the programming language to prevent certain issues - SQL injection for example is something that should be handled by the framework (by not allowing to write SQL directly, but using commands with parameters). All the other higher priority issues are like that, it's not within the scope of a language to prevent such issues, just as Rust or Zig or whatever will never prevent phishing attacks.
As for temporal vs spatial memory safety issues, I agree that Zig does maybe help in that a bit (if component A sends an event to B, then A,B and the events having a separate allocator would work) - though I'm not sure if it doesn't introduce its own footguns (how do I know which allocator needs to free which object).
I don't know I haven't used Zig at all, so no idea how all this works out in practice. Memory issues are 100% solved by languages like Java with GC and I wouldn't say they have made software that much less buggy.
> it's not within the scope of a language to prevent such issues
As someone working on adding such a feature to Java, I beg to differ. Python has also recently added a language feature to address injection attacks (https://peps.python.org/pep-0750/).
> Memory issues are 100% solved by languages like Java with GC and I wouldn't say they have made software that much less buggy.
Well, again, the question isn't how many bugs you have, but what the impact of these bugs is. Violations of spatial memory safety are both common and relatively easy to exploit into very dangerous attacks, which is why it's important that Rust and Zig prevent them. But everything is a question of cost and benefit, as in, how much extra effort, or RAM, or CPU it's worth it to avoid certain bugs. The answer depends on the nature of the bug, the nature of the project, and the preferences of developers. Zig and Rust compromise on both correctness and effort, but their compromises are somewhat different. We just don't know if one of these approaches is more likely to be a better sweet spot in more situations (where these languages are used), and if so which.
As for temporal vs spatial memory safety issues, I agree that Zig does maybe help in that a bit (if component A sends an event to B, then A,B and the events having a separate allocator would work) - though I'm not sure if it doesn't introduce its own footguns (how do I know which allocator needs to free which object).
I don't know I haven't used Zig at all, so no idea how all this works out in practice. Memory issues are 100% solved by languages like Java with GC and I wouldn't say they have made software that much less buggy.