It is time to standardize principles and practices for software memory safety
14 comments
·February 6, 2025userbinator
stavros
The ability to jailbreak should be a legal right. We shouldn't be relying on vulnerabilities just to own the devices we bought.
mcpherrinm
It’s time to stop governments from hacking people’s phones, taking away their privacy?
Users should have control and trust in their devices. If they can be remotely compromised, they cannot get that.
deadliftdouche
ultimaweapon
You are very unlikely to hit this bug in a real world Rust project while C/C++ you can easily hit by a memory safety bug.
weinzierl
Exactly, and also MIRI catches all of these, so with a tiny little extra effort world is in order again.
Moreover, if I remember correctly, they all are made possible by a single (long-standing) compiler bug that eventually will be fixed.
Previously discussed: https://news.ycombinator.com/item?id=39440808
I think this mindset is the big difference. We're not perfect, but we're working on it.
flitzofolov
Makes sense, good luck! I know that sounds snarky, I'm looking forward to rational progress and cooperation on the evolution and adoption of the standard. Just haven't seen that played out in such a planned orderly fashion yet (ipv6?).
leecommamichael
Yeah, I’m wondering what this even means. I’m assuming they’ll have to define “memory safety” which is already quite the task. Memory safe in what context? On what sort of machine? What sort of OS?
User23
One of the most under appreciated things about the JVM is its well-defined memory model.
SOLAR_FIELDS
Is it a hot take to believe that no humans are infallible and that only languages with memory safe guarantees can offer the kind of safety the author seeks? With the advent of rust, c and c++ programmers can no longer argue that the performance tradeoff is worth giving up safety.
There are, of course, other good reasons to choose c and c++ over rust. And of course rust has its own warts. just pointing out that performance and memory safety are not necessarily mutually exclusive
RossBencina
I'm not sure what you're definition of performance parity is. Are you claiming that the existence of rust proves that there is no performance penalty for memory safety? The penalty may be relatively small, but I am not aware of any proof that the penalty is non-existent. I am not even sure how you could prove such a thing. I could imagine that C and C++ implementations of exactly the same algorithms and data structures as are implemented in safe rust might perform similarly, but what about all of the C and C++ implementations that are both correct and not implementable in safe rust? do they all perform only as well or worse than rust?
vvanders
That assumes that people know what they're doing in C/C++, I've seen just as many bloated codebases in C++ if not more because the defaults for most compilers are not great and it's very easy for things to get out of hand with templates, excessive use of dynamic libraries(which inhibit LTO) or using shared_ptr for everything.
My experience is that Rust guides you towards defaults that tend to not hit those things and for the cases where you really do need that fine grained control unsafe blocks with direct pointer access are available(and I've used them when needed).
Tanjreeve
Is there a name for a fallacy like "appeal to stupidity" or something where the argument against using a tool that's fit for the job boils down to "All developers are too dumb to use this/you need to read a manual/it's hard" etc etc?
It's time to stop jailbreaking/rooting, fully take control away from the user and enforce DRM more strongly?