9 ms·
Memory safety is table stakes
- timewizard 1y ago> if it compiles, then it’s correct … or at least, will not contain use-after-free or other memory safety errors In a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You have no guarantee of any significance. You've just slightly changed where the security boundary _might_ lie. > There is a great amount of software already written in other languages. Yea. And development of those languages is on going. C++ has improved the memory safety picture quite a bit of the past decade and shows no signs of slowing down. There is no "one size fits all" solution here. Finally, if memory safety were truly "table stakes" then we would have been using the dozens of memory safe languages that already existed. It should be blindingly obvious that /performance/ is table stakes.
- noisem4ker 1y ago> It should be blindingly obvious that /performance/ is table stakes. I think a big part of it is just inertia.
- dwattttt 1y agoIt's been a very slow learning process trying to undo the "performance at every cost" mantra.
- AlotOfReading 1y agoIn a language with the `unsafe` construct and effectively no automated tooling to audit the uses of it. You can forbid using unsafe code with the lints built into rustc: https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/builtin/static.UNSAFE_CODE.html https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/bu... Cargo allows you to apply rustc lints to the entire project, albeit not dependencies (currently). If you want dependencies you need something like cargo-geiger instead. If you find unsafe that way, you can report it to the rust safety dance people, who work with the community to eliminate unsafe in crates. All of this is worlds ahead of the situation in C++.
- vlovich123 1y agoOP is wrong that there's no tooling. All the C++ tooling that I'm aware of (e.g. ASAN/UBSAN/MSAN/TSAN) is still available on Rust. Additionally, it has MIRI which can check certain code constructs for defined behavior at the MIR level which, unlike sanitizers, validates that all code is sound according to language rules regardless of what would be run by generated assembly; this validation includes unsafe code which still has to follow the language rules. C/C++ doesn't have anything like that for undefined behavior by the way. However, if I can apply a nitpicking attitude here that you're applying to their argument about the ease with which unsafe can be kept out of a complex codebase. unsafe is pretty baked into the language because there's either simply convenient constructs that the Rust compiler can't ever prove safely (e.g. doubly-linked list), can't prove safely today (e.g. various accessors like split), or is required for basic operations (e.g. allocating memory). Pretending like you can really forbid unsafe code wholesale in your dependency chain is not practical & this is ignoring soundness bugs within the compiler itself. That doesn't detract from the inherent advantage of safe by default.
- AlotOfReading 1y agoI do safety critical code. I would consider banning allocation (e.g. just using Core) or avoiding certain data structures a completely feasible strategy to avoid unsafe if I wanted to exclude it from my safety model. It's what I'm already doing in C++. The difference is that in C++, I can never prove the absence of undefined behavior from any part of the codebase, even if I review every single line. Even if I could, that proof might be invalidated by a single change anywhere. It's not easy in Rust, but it's possible.
- imglorp 1y agoThat's an extreme take now and maybe uncharitable. The safe parts of rust are simply no comparison to the whole c/c++ world: the tooling is eliminating vast swaths of "easy" errors. Unsafe parts might be comparable if they're calling the same libraries. Industry is seeing quantifiable improvements, eg: https://thehackernews.com/2024/09/googles-shift-to-rust-programming-cuts.html https://thehackernews.com/2024/09/googles-shift-to-rust-prog...
- xvedejas 1y agoSafe rust is a safe language. Yes, it is built upon unsafe rust. But I still consider Python to be a memory safe language despite it being built on C. I can still trust that my Python code doesn't contain such memory errors. Safe Rust is the same in terms of guarantees. That's all that anyone is claiming.
- UltraSane 1y agoIt is a lot like how you have to trust the core proving kernel in a theorem prover but if you do then you can trust every proof created using it.
- burnt-resistor 1y agohttps://github.com/CertiCoq/certicoq https://github.com/CertiCoq/certicoq can prove (most of) itself.
- burnt-resistor 1y agoThe main problem now is that there isn't a platform that has the tooling or infrastructure to prove, including through formal methods, that they are correct and free from bugs in the spirit of the seL4 project.
- zaphar 1y agoLanguages with unsafe don't just change where the security boundary lies. It shrinks the size of the area that the boundary surrounds. C++ has artificially limited how much it can improve the memory safety picture because of their quite valid dedication to backwards compatibility. This is a totally valid choice on their part but it does mean that C++ is largely out of the running for the kinds of table stakes memory safety stuff the article talks about. There are dozens of memory safe languages that already exist: Java, Go, Python, C#, Rust, ... And a whole host of other ones I'm not going to bother listing here.
- torstenvl 1y ago[flagged]
- School-Cotton 1y agoWhat does “proprietary” mean to you?
- torstenvl 1y agoIt doesn't mean anything "to me." Its meaning is clear and objective and applies to every language listed above.
- School-Cotton 1y agoOkay, please explain in what sense Python or Rust is proprietary.
- torstenvl 1y agoIn all senses. They are both 100% proprietary. There is no sense in which either language is anything other than proprietary. It is literally illegal for me to start marketing The TorstenVL Rust Compiler. Because the language is proprietary.
- tialaramex 1y ago> It should be blindingly obvious that /performance/ is table stakes. Nah, there's a famous WG21 (the C++ committee) paper named "ABI: Now or Never" which lays out just some of the ever growing performance cost of choices the committee has made to preserve ABI and explains that if this cost is to be considered a price paid for something the committee needs to pick "Never" and if they instead want to stop paying the price they need to pick "Now" and, if as the author suspects, they don't actually care, they should pick neither and C++ should be considered obsolete. The committee, of course, picked neither, and lots of people who were there have since defended this claiming that this was a false dilemma - they were actually cleverly picking "Later" which that author didn't offer. Each time they've repeated this more time has passed yet they're still no closer to this "Later" ...
- marsven_422 1y ago[dead]
- nick_ 1y agoIf Rust is the language that finally overwhelms the resistance to memory safe languages, that's good. I think it's also important not to centre Rust alone. In the larger picture, Rust has a combo of A) good timing, and B) the best evangelism. It stands on decades of memory safe language & runtime development, as well as the efforts of their many advocates.
- tptacek 1y agoI think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python). We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.
- Ar-Curunir 1y agoand cryptographic code.
- wglb 1y agoMy favorite crypto bug was not a memory safety issue: https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squ... Was a fascinating detective story to illustrate it.
- olarm 1y ago> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems. And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.
- zahlman 1y agoTo be fair, there's a pretty clear difference between achieving memory safety with a garbage collector and run-time type information, versus achieving it through static analysis.
- b0a04gl 1y ago[dead]
- xTachyon 1y ago[flagged]
- Ar-Curunir 1y agoYou can just read the paper instead of making negative comments: https://patpannuto.com/pubs/schuermann2025omniglot.pdf https://patpannuto.com/pubs/schuermann2025omniglot.pdf They are in particular careful to never state that bindgen emits the wrong code. Maybe they could have said that bindgen in fact does handle this case correctly. But Omniglot seems to be doing a lot more than bindgen, and
- IshKebab 1y agoWell... he does have a point. Don't demonstrate your great tool with an issue that the existing solution doesn't actually have.
- ARob109 1y agoLearning Rust ATM and using bindgen on a C header. Just looked and it generates Rust enums from C enums. I'm not sure what the default behavior of bindgen is, but it seems there is option for constifying enums --constified-enum <REGEX> Mark any enum whose name matches REGEX as a series of constants --constified-enum-module <REGEX> Mark any enum whose name matches REGEX as a module of constants IMO, saying bindgen avoids the issue presented in the article is not accurate. edit: formatting
- taping-memory 1y agoI'm reading the article and so far it's great. I'm just wondering in the explanation of listing 2 you say: > a discriminant value indicating the enum’s active variant (4 bytes) As far as I can find, there's no guarantee for that, the only thing I can find is that it might be interpreted as an `isize` value but the compiler is permitted to use smaller values: https://doc.rust-lang.org/reference/items/enumerations.html#r-items.enum.discriminant.repr-rust https://doc.rust-lang.org/reference/items/enumerations.html#... Is there any reason to say it should be 4 bytes? It doesn't change any of the conclusions, I'm just curious
- OptionOfT 1y agoUsing repr(C) makes it 4 bytes. But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those. But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.
- taping-memory 1y ago> Using repr(C) makes it 4 bytes. That makes sense, they just don't use repr(C) for the PrintResult so I didn't consider that. > But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those. That makes sense but if there could be a way to safely generate code that converts to an enum safely as proposed in the article that would be good as the enum is more idiomatic. > But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated. The signature for async_print in C is `async_res_t async_print(const *uint8_t, size_t)` and they are passing a pointer to a &[u8] created from a byte string literal, so I think it's correct.
- 0xbadcafebee 1y agoLisp, Algol 68, Pascal, Smalltalk, ML, all had both memory safety and type safety. Nobody uses it today. Why? Because software isn't developed by rational beings choosing the best tool for the job. It's developed by humans who are influenced by their cultural norms and environment. You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit. Write all the papers you want; as long as the inmates are running the asylum, there is no safety.
- ksec 1y agoI am the only one on HN that brings up Ada because I think it deserve some credit. But then it seems there are a lot of hate towards Pascal style syntax.
- johnisgood 1y agoI bring it up all the time. :P
- pron 1y agoAlgol 68 and Pascal weren't memory-safe, and as for Lisp, Smalltalk, and ML, their style of memory safety - based on GC - took over the world pretty much the second it became practical enough for widespread use. It is true that some decisions people make aren't rational, and it may even be true that most decisions most people make aren't entirely rational, but the claim that the whole software market, which is under selective pressures, manages to make irrationally wrong decisions in a consistently biased way is quite extraordinary and highly unlikely. What is more likely is that the decisions are largely rational, just don't correspond to your preferences. It's like the VHS vs. Betamax story. Fans of the latter thought that the preference for the former was irrational because of the inferior picture quality, but VHS was superior in another respect - recording time - that mattered more to more people. I was programming military applications in Ada in the nineties (also not memory-safe, BTW) and I can tell you we had very good reasons to switch to C++ at the time, even from a software correctness perspective (I'm not saying C++ still retains those particular advantages today). If you think so many people who compete with each other make a decision you think is obviously irrational, it's likely that you're missing some information.
- djha-skin 1y agoNope: ease of use is table stakes. Rust is not easy to use. It will never become mainstream because of this. For all its faults, C is comparatively simple.
- another_twist 1y agoI actually think rust is very very easy to use to the point where I'd consider using it for scripting. They need to write out more detailed guides on how to do X with Rust though. e.g there's no runtime polymorphism in Rust since every trait + struct binding is unique. However, it similar behaviour can be accomplished by generics hence so many angular brackets in normal Rust code.
- TylerE 1y agoI find attitudes like this simply bizzare. nothing about rust is 'easy' no matter how much it's fans insist it so. Just the syntax is miserable punctuation soup to start with.
- 0x1ceb00da 1y agoNot saying rust is easy, but syntax wouldn't even be in the top 5 if I had to list things that make rust difficult.
- justinrubek 1y agoIt always amazes me what things people will latch on to. There are many valid criticisms to be had, but those aren't the focus points of the debates.
- Measter 1y agoBut many of those valid criticisms require some familiarity with the language. With syntax they can just point at it and claim it's bad without having to learn anything first.
- 1y ago
- userbinator 1y ago[flagged]
- Noelia- 1y agoI used to work on an old C project where everyone knew there were memory issues, but no one wanted to touch it. Rewriting was too expensive, so we just used tools to keep it running. Now most new projects go with Rust. Memory safety feels like the default, but it's going to take time for the old stuff to catch up.
- Animats 1y ago"Omniglot" is a rather dramatic title for something that's basically a way to call C from Rust with additional checking on the C side for type compatibility. That said, it might be useful. The demo case is contrived, though. Passing Rust async semantics into C code is inherently iffy. I'd like to see something like OpenJPEG (a JPEG 2000 encoder written in C) safely encapsulated in this way.
- comradelion 1y agoWhat would you say to libpng, libsodium, Brotli, LwIP, LittleFS, and CryptoLib? https://patpannuto.com/pubs/schuermann2025omniglot.pdf https://patpannuto.com/pubs/schuermann2025omniglot.pdf
- halis 1y agoRust is starting to feel like those people calling about your car’s extended warranty.
- tom_m 1y agoOddly I see a lot of marketing for Rust. Not gonna make it a success, sorry. No one cares about Rust lol. It's specialized. It has a value and a place, but it isn't a mainstream thing unfortunately.
- spoiler 1y agoWhat gives you the impression it won't be mainstream at some point? Its adoption seems to be on steady but slow rise. Also I think there's other great things about Rust other than _just_ memory safety