top | item 36996595

(no title)

quic5 | 2 years ago

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error?

What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

discuss

order

nevi-me|2 years ago

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

lmm|2 years ago

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.

memefrog|2 years ago

>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.

quic5|2 years ago

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.

jdrek1|2 years ago

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.

throwawaymaths|2 years ago

> 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?

grumpyprole|2 years ago

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.

johnisgood|2 years ago

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.

TheFragenTaken|2 years ago

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?

Ygg2|2 years ago

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