Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.
We’re really talking about safety on a continuum, not as a binary switch. Zig has some strong safety features, and some gaps. Well, one notable big gap, UAF. (Perhaps they’ll figure out a way to plug thisin the future? Perhaps by 1.0?)
Actually, safety has multiple axes as well.
> Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue
The more safe languages make significant tradeoffs to achieve their level of safety. The promise of zig (I don’t know if it will ultimately achieve this, but it’s plausible, IMO), is “a better C”, including much more safety. For one thing, it has a great C interop/incremental adoption story, which increases the chance it will actually be used to improve existing codebases. The “RIIR” meme is a joke because, of course, there is no feasible way to do so for so many of the useful and widely used vulnerable codebases.
I am somewhat surprised this is being mentioned. And the whole thread is without the usual people complaining it about unsafe.
Interesting changes happening on HN.
"Logical Foundations for the Future of Safe Systems Programming"
https://cordis.europa.eu/project/id/683289
As for US,
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
"NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. Memory safe languages provide differing degrees of memory usage protections, so available code hardening defenses, such as compiler options, tool analysis, and operating system configurations, should be used for their protections as well. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit."
Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust).
There are plenty of use cases where none of these tradeoffs are feasible.
To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehensive as other languages.
Perhaps as an escape hatch (unsafe Rust) or a compiler target, but ideally not as a "general purpose language" as Zig is marketed as.
The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.
"The use is necessary" = absolutely not. Lots (most) of projects wouldn't ever need to dip into 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.
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're not limited by anything there, period.
What I'm trying to say: There are use cases where areas of safety are required other than memory safety.
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.
Operating system bootstraps?
DMA management/volatile driver access?
Doubly linked lists?
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.
Number of memory bugs in several fairly huge projects: 0
Zig is way more maintainable, leads to less code which translates to fewer bugs
How about that?
"The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities."