Just somewhat related to the article but I think one thing which is often misunderstood about rust's is it's borrow checker. The borrow checker is not about me

Just somewhat related to the article but I think one thing which is often misunderstood about rust's is it's borrow checker. The borrow checker is not about memory safety but about aliasing guaranteed. It just happen that combining this with deterministic destructors (/RAII) happend to enable reliable "automatic-manual-memory-management" (or however to callit). And combining it with some clever auto traits (Send/Sync) happen to prevent data races (if no unsafe is used, like always). But the benefits are not limited to just that. Not just memory-resource management but also other resource management profits from this design. Similar while Send/Sync is about multi threaded data race prevention there are also problems in single threaded patterns which are quite similar to that e.g. "racing" between iterating a collection and changing it in the body of the iteration, and the aliasing guarantees make sure you don't have such problems either. Similar rusts main pointer type (`&`) does not only provide compiler time non-null guarantees but also provides compiler time guarantees about how the data can be accessed (dereferencable, writeable etc.). And then there is the choice to use the type system to prevent application logic bugs in many ways. So the bullet points in the table miss many dimensions . But then zig is still a grate language, but trying to convince people that it's good enough by telling them that not reusing allocations seem to not be the best way. Instead look at arguments why people still use C today (not C++!) what they conceptually like about it and you might realize many of the parts still apply to Zig. Honestly Zig seems to be a grate choice for webasm or similar sandboxed systems where the potential damage of use-after free or double frees can be massively reduced.