Zig 0.11

That is a big may, given that it depends pretty much on what is being done in terms of code, and compile time execution (C++ and Rust), and many of the same compiler knobs are also available for C++ code, if not even more.

And was you point out, at the end of the day it is the same LLVM IR.

> You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.

No, you can't. The standard library contains 'unsafe', all over the place. Even if you discount that, large swathes of the library 'ecosystem' contain 'unsafe' and those that don't? They depend on libraries that do.

>"The use is necessary" = absolutely not.

Relying on some unsafe code that someone else has written is still using unsafe. The code in your dependencies is code that you use, that you depend on, and that affects you. It is meaningless to say you 'don't use unsafe code' if your code is just plumbing together a bunch of libraries that contain 'unsafe' code.

>And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.

This common sentiment from Rust developers is, just like all their other claims, totally unfounded. 'Oh you don't really need unsafe'. Then you explain why actually, yes, you do need unsafe and you're told that you're describing a 'special case'. Well guess what, every project is a special case in some respect. Every nontrivial project is going to have something that requires unsafe code, whether it's interfacing with hardware or using a system call that hasn't been wrapped or using a third party library or implementing a complex data structure or one of many many other various things that require 'unsafe'.

And even if you don't use 'unsafe' anywhere in your code and you somehow magically know that all of your dependencies are perfectly written and all the soundness bugs in the Rust compiler are fixed (at which point you might well ask: if you can assume all your Rust dependencies are perfect, why can't you assume all your C dependencies are perfect? And also, how can you be confident in any 'unsafe' code being safe if the rules for what is 'safe' to do in unsafe aren't even written down anywhere?), then what do you get? Almost nothing. 'Memory safety' is a very narrow category. As I said above, it means 'things Rust protects against'. It wasn't a term that was popularly used before Rust became known in the way Rust means it. Even to most Rust developers and contributors, right up until release it was widely assumed that it included leak freedom. And then a couple of weeks before release that was quietly dropped and memory-holed when it was shown that you could introduce memory leaks trivially. Large amounts of supposedly 'safe' unsafe code had to be rewritten and redesigned.

Rust just doesn't give you any the guarantees that Rust evangelists love to claim. Even in memory safety. In fact, almost every language out there is MORE safe than Rust, in the sense in which Rust claims to be memory-safe! The only ones that aren't are those without garbage collection.

You can't prove it in Rust either.

That was the point I was trying to make, Zig isn't inherently faster than the other three. It just uses different default compilation options than clang, so any gains can be achieved in clang-compiled C or C++ too by tweaking compile options (and maybe using a handful non-standard language extensions offered by clang). Other then that it's just LLVMs "zero cost abstraction via optimization passes" and this works equally well across all 4 languages.

Or: the "optimization wall" in those languages is the same, only the effort to reach that wall might be slightly different (and this is actually where Zig and its stdlib might be better, it's more straightforward to reach the optimization wall because the Zig design philosophy prefers explicitness over magic)

If you can't see why jailing people for writing JS is a comically absurd concept…