[dadrian]

There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.

[bastawhiz]

That's really just not true. Easy counterexample: any codec should be written in a memory safe language.

Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.

[tialaramex]

In fact codecs in particular should be written in something much stricter but more special purpose than Rust, WUFFS (Wrangling Untrusted File Formats Safely)

https://github.com/google/wuffs

WUFFS gives up generality - you can't write "Hello World" in WUFFS because it lacks both strings (for the "Hello, world" text) and I/O (for the printing it out). But you can write a codec, going from a block of bytes representing the encoded file to a block of bytes representing pixels, or PCM audio, or indeed uncompressed data [or vice versa] is easy.

But unlike Rust, all of the safety in WUFFS was checked during compilation. For example Rust emits bounds checks, arr[n] might panic at runtime if n is outside the bounds of arr, but WUFFS doesn't do that, it'll have proved mathematically that n is always in-bounds, if it can't prove that it rejects your code, make sure n is in bounds and try again.

Sometimes the end result is similar, you write code to check n at runtime, if it's a miss you report an error, WUFFS can see you met the criterion - basically the same as Rust. But often in a codec design you can just prove it's in bounds, if you implemented it correctly.

[ssokolow]

*nod* As someone who came from Python for easier maintainership (strong compile-time checks, an ecosystem that tries to follow the toolchain's "fearless upgrades" philosophy, almost Go-like ease of deployment, etc.) I'd LOVE if someone made a Rust implementation of WUFFS so I didn't have to choose between stronger compile-time checks and less painful build automation and cross-compilation.

[pjmlp]

Yes, DSLs or formal verification tools are a much better solution for many scenarios.

[procflora]

And how about safety of life systems? They use computers in chemical plants and on planes, you know lol. Integer overflows have a body count!

[tialaramex]

In these applications we want what's called "Functional safety" where what we care about is that the humans are kept safe. A Memory Safe language can be useful to help achieve this, which is why https://ferrocene.dev/ exists but it's also important to have business processes to assure that what the software is supposed to do will keep the humans safe, memory safety doesn't distinguish between "Ensure the human operator is in the containment zone when a cloud of toxic vapour is released" and "Ensure the human operator is NOT in the containment zone when it is released". But for that operator this difference is crucial.

[xboxnolifes]

I kinda wish we didn't push with the term "memory safe", and instead had a push with "correct". If your software isn't memory safe, it does not work correctly. We should aim to have software that works correctly.

[ssokolow]

The word "correct" already had a meaning. Memory safety is a subset of correctness in the same way that Rust can't statically prevent race conditions but it can prevent a subset of them called data races.