It sounds like you'd be worrying about n-1 types of safety errors instead of n, which is arguably better.

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

>there are no use cases where memory unsafety is desirable, yet alone required.

There are plenty of 'use cases' where Rust's guarantees (some vague but unenforceable promises around memory) are not worth the cost of using Rust (a very high cost). This is doubly true if you want to, say, not use any third-party libraries. If you use third-party libraries, you get essentially zero guarantees. And if you don't, you have to reinvent the world - and writing new data structures in Rust is a series of research projects, whereas doing so in C is trivial.

There are many situations where guaranteed 'memory safety' (a Rust propaganda term for 'having the guarantees we can provide but not the ones we can't provide') is not very important.

That is absolutely true. But but you can write memory-bug-free code in Zig but you cannot prevent heap allocations in most of the languages listed in the article, making it outright impossible to write certain software in them.

Sure one can write memory-bug-free code in x86 assembly too. But how can you prove it? ATS is an example of a low-level systems language where you can prove it.

As Zig promises "not hidden allocation", I assume you can build your allocator in Rust and then use it for all memory allocation in Zig.

A function that doesn't allocate doesn't mean it's safe. (Indeed if anything the opposite is more likely - copying is safe, if slow, writing to something that was passed in tends to be what breaks).

You can't prove it in Rust either.

formalized subsets of x86 assembly exist. Coq can be used as a macro assembler. tools to work with llvm ir exist, x86 can be raised up to llvm ir and proved, kinda bad way tho.

While that is true, there might be other requirements that prevent memory safe languages from being used. For example not having a heap available instantly disqualifies most of them. Or when you have simulations running where having constant OOB and other checks would be a massive slowdown. Now obviously your code should still be memory safe (because otherwise it's not correct anyway and you should fix the code), but not at the cost of runtime checks.

> But there are no use cases where memory unsafety is desirable, yet alone required.

Operating system bootstraps?

DMA management/volatile driver access?

Doubly linked lists?

Memory safety is one aspect of quality yes, but is there any evidence Zig is a good fit for other quality aspects, e.g. static analysis tooling and correctness proofs? ATS is a low-level language that allows embedded proofs of correctness in the type system.

That article does not even mention Ada/SPARK... So much for safety. :P Yup, there is static analysis with Ada/SPARK and it is great. It is much more general-purpose than ATS, and there are other things in Ada/SPARK that increases safety in general, not only memory safety.

For what it is worth, Ada/SPARK has a strong presence in safety-critical domains like aerospace and medical devices, while Rust is gaining popularity in system programming and web development. ^^ I'm surprised that it is not as widespread. That, or lots of misconceptions.

Yes Ada/SPARK is a great example.

Not to be snarky, but you argument works both ways :). What good is a medical device if it leaks sensitive data, because it had been exploited by a use-after-free?

Memory errors are much, much less likely to occur with more memory than use after free.