I'm not saying that memory unsafety is useless or even undesirable, I think the "problem" is that it's the default in "current popular and actually used high-performance languages", which means that stuff that needs to be fast and secure (like web browsers) have a hard time.
Maybe my "most of the time" was too strong and I ignored big domains that I don't know. But for the part that I relatively know (web stuff mostly), safety and speed together matters a lot. The thing is, since unsafety tends to be viral (an unsafe part of your stack can compromise everything), people get very paranoid about "unsafe languages".
This isn't about choosing security measures from a menu. This is about the foundations of what you build.
To the extent that memory safety is slowly, oh so slowly, but steadily dropping down the list, it is because we are taking it seriously as a foundational issue and actually addressing it. To turn around and then use the success we've had as evidence that it isn't important is making a serious error.
There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs. Even if you do have one of the rare cases when you need it, and you only need a very particular variant of it (reading bytes in memory of one type as bytes of another type, you never need to write out of the scope of an array or dereference into an unallocated memory page), you can still get it through explicit unsafe support that every language has one way or another. You do not need a language that is pervasively unsafe with every line you write so that on those three lines of code out of millions that you actually need it, you can have it with slightly less ceremony. That's just a mind-blowingly bad tradeoff and engineering decision.
How are we supposed to address the other issues from a foundation of a memory unsafe language? If we can't even have such a basic guarantee, we sure aren't going to get more complicated ones later.
The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.
Memory safety is valuable! I wouldn't want to implement anything in a memory-unsafe language if I could avoid it, and, thanks to Rust, I can virtually always avoid it now. There's ways to make bugs easier to chain and exploit, and memory unsafety is a big one.
But, while I know nothing is a panacea, memory safety is especially not a panacea. We have over a decade worth of experience with software built principally in memory-safe languages; it's hard to find a modern web application --- increasingly, it's even hard to find a modern mobile application --- built in a language as bad as C. And, as you know, all these memory-safe applications are riddled with vulnerabilities. They don't have memory corruption vulnerabilities, but I'm still game-over'ing app pentests, and very unhappy with myself when I can't.
"Memory unsafe languages" is maybe one percent of one percent of the problem.
As always, nobody actually gives a damn about "security" and uses it as a pretext to push something unrelated. (In this case, Current Year's stupid fad programming language.)
I've never understood the obsession with memory-safe languages. I get that they are easier to program in and they eliminate certain classes of bugs, but most end users don't care. They just want a product that works. The security argument also makes less sense for browsers because most web app exploits are unrelated to memory safety.
Of course, but memory unsafety is one of the biggest enabler for security vulnerabilities. Attackers have shifted to other concerns when PHP became widespread enough for example, but PHP alone cannot be used to create a vulnerability common in C/C++ because of its memory safety (which is not even that good!), you need some other systems to combine multiple issues into a single coherent attack, and it's likely that C/C++'s memory unsafety has played a great role somewhere in between. He doesn't fully acknowledge this multiplicative aspect of memory (un)safety.
I'm not sure what "memory safety" has to do with skill regarding "language architecture." In fact, I'm not quite sure what you mean by that whole bit.
Memory safety isn't a bad thing. But maybe pushing it as the thing will end up making it harder for newer systems programmers to be comfortable dropping into "unsafe-Rust" when it's necessary out of fear, or harder for them to learn the lessons that C and C++ folks have had to when they do have to use "unsafe-Rust". We just don't know what the impact will be in that regard. It's part of being a young language--it just needs time to develop.
Well, then, three languages scratched off my list. At least, assuming y'all are using the correct definition of "memory safe".
There is no sensible reason in 2023 for a language to be memory unsafe. What tiny performance advantages can be eked out are completely and utterly trounced by the multi-decade history of the catastrophic errors made and security vulnerabilities created. Whatever performance optimizations could be made are either A: a bad idea anyhow or B: if not actually a bad idea, available through the use of "unsafe" blocks in an otherwise safe language anyhow.
unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.
This seems like a long axiomatic rationalization for using memory-unsafe languages. "[W]ith the right tooling, practices, and discipline, one can reduce the risk of memory safety bugs to an acceptable level for their situation". Well, empirically, no, that's not the case: the largest, most sophisticated teams in the world have tried, and it hasn't worked out.
You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains:
A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this.
We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side.
Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
His point is that in the world of programming languages, "true memory safety" isn't really something achievable without making it impossible for your language to interact with things like native libraries or the OS. Given this, the concept of "true memory safety" isn't a useful one. In general when you say a language is memory safe, there's an implicit caveat that there may be explicit escape hatches. No language (except perhaps web-based JS) is "memory safe" by the strict definition so it's not a useful parameter to use when talking of languages. You instead use the weaker version.
That’s a dangerous line of thinking: memory safe languages can and do have memory safety bugs. There are many causes for this, from incorrect compilation (as seen here IIUC), bugs in the language runtime, concurrency problems, to unsafe language features. That doesn’t mean that there is no value in memory safe languages, they are a definite improvement. But, they are not the solution to all problems around memory safety. For example, even in Rust, which provides some of the strongest memory safely guarantees, there are memory safety issues discovered in the standard library.
I didn't say that memory safety is not important. I was talking about the need to control memory layout and other bells and whistles.
Anyway, you suggested Rust under false assumptions. Rust doesn't care about reliability and security any more, than most of the modern languages. Even Perl with its taint mode is more secure, than Rust.
It isn't "going to be". It is, and it has been for a long time.
Lots of people confusing "memory safety" with the high degree of thread safety offered by Rust. Memory safety is in everything modern except C and C++, and ASM. It's the present baseline, except those.
Nobody is proposing new memory unsafe languages.
Only a few straggler developers, possibly with the same confusion, are loudly insisting they somehow need memory unsafe languages. When you consider what "memory unsafety" means, the claims are transparently risible. Nobody needs the ability to access arrays out of bounds. Nobody needs access to unallocated memory. It's not a serious desire, it's just contrarianism or confusion about what it is.
Maybe my "most of the time" was too strong and I ignored big domains that I don't know. But for the part that I relatively know (web stuff mostly), safety and speed together matters a lot. The thing is, since unsafety tends to be viral (an unsafe part of your stack can compromise everything), people get very paranoid about "unsafe languages".
reply