6 ms·

This is the bomb that sank C++ in 2026. Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great

by mk89 11mo ago

This is the bomb that sank C++ in 2026. Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great dev you can do even better, etc.

gchamonlive 11mo ago
I personally have zero interest in these feud wars. I'm only glad there are more quality options for Devs to develop safer system tools.
- josephg 11mo ago
  The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling. Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the new languages were GC, and paid for their shiny features with poor runtime performance. (Eg java, C#, Ruby, Python, lua, go, etc etc) Rust is a fine language. Personally I can’t wait to see what comes after it. I’m sure there’s even better ways to implement some of rust’s features. I hope someone out there is clever enough to figure them out.
  - bgwalter 11mo ago
    [flagged]
    - aw1621107 11mo ago
      > Even in its own "memory safety" definition, which is the first result on Google, they criticize C instead of providing a proper definition: I'm not sure that page is intended to provide a definition of "memory safety" in the first place? It (and the following page) seem more intended to introduce safe/unsafe Rust and the boundaries between the two. It's also from the Rustinomicon, which states: > Unlike The Rust Programming Language, we will be assuming considerable prior knowledge. In particular, you should be comfortable with basic systems programming and Rust. So it's arguably unsurprising that a definition of memory safety would not be found there. My guess is that if you want a more precise definition you'd want to look at the Rust Reference (e.g., [0]) or in related areas. [0]: https://doc.rust-lang.org/reference/unsafety.html https://doc.rust-lang.org/reference/unsafety.html
    - Inityx 11mo ago
      I don't think materially contrasting yourself with your direct competition quite constitutes a "feud war"
      - bgwalter 11mo ago
        The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible. Which is a pity, because the language itself does not seem to be so bad.
        josephg 11mo ago
        > Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response. > The Rust literature is poorly written compared to C and Ada I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing? I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library: https://doc.rust-lang.org/std/iter/trait.Iterator.html https://doc.rust-lang.org/std/iter/trait.Iterator.html Every function in that interface is well documented, with examples. Here's the equivalent for C++: https://en.cppreference.com/w/cpp/iterator/iterator.html https://en.cppreference.com/w/cpp/iterator/iterator.html Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far. So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here: http://www.lmdb.tech/doc/group__mdb.html http://www.lmdb.tech/doc/group__mdb.html In rust, any published crate automatically has a docs.rs/cratename link. Eg for serde's reference manual: https://docs.rs/serde/ https://docs.rs/serde/ And then for the "guide" style explanation they wrote a book: https://serde.rs/ https://serde.rs/ Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
    - josephg 11mo ago
      > That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad! I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety? The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing? When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.
beeflet 11mo ago
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.
- gpm 11mo ago
  > I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.
  - petcat 11mo ago
    Yeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
    - kridsdale1 11mo ago
      It’s https://en.wikipedia.org/wiki/Bazel_(software) https://en.wikipedia.org/wiki/Bazel_(software)
  - kridsdale1 11mo ago
    Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing. If I were to go to another company I’d promote using either of the above.
    - vlovich123 11mo ago
      What does Android do for Rust?
      - 11mo ago
tick_tock_tick 11mo ago
I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust. (doesn't mean it's not an improvement on C++)
- ViewTrick1002 11mo ago
  The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land. All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues because they are treated as bugs. It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.” https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22I-unsound%22 https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
- selfmodruntime 11mo ago
  This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
  - tick_tock_tick 11mo ago
    Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b5ac5ef8f2928dcaab148fc911c12c5e https://play.rust-lang.org/?version=stable&mode=debug&editio... I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/25860
    - dwattttt 11mo ago
      Yes, that's an existing soundness hole in the compiler. You won't accidentally code it up yourself though. If the bar is "deliberately malicious code results in a segfault", get back to me when they fix memcpy(0x10000, 0x20000, 0x10); EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.
deleted 11mo ago
[deleted]
ActorNightly 11mo ago
Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative. That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
- kibwen 11mo ago
  > That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does. Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is nontrivial.
  - ActorNightly 11mo ago
    Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem. The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold. But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id. So you simply have a system of tracing where memory gets used. But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.
    - josephg 11mo ago
      So your claim is that sufficiently careful C is just as safe as rust? Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion: > Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.
jandrewrogers 11mo ago
It really depends on the type of software.
pjmlp 11mo ago
Nope, Rust compiler depends on LLVM and GCC (ongoing), both written in C++. Then there are enough industry standards that are defined for C and C++, where Rust isn't even visible.

by mk89 11mo ago

This is the bomb that sank C++ in 2026. Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great dev you can do even better, etc.

gchamonlive 11mo ago

I personally have zero interest in these feud wars. I'm only glad there are more quality options for Devs to develop safer system tools.

josephg 11mo ago
The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling. Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the new languages were GC, and paid for their shiny features with poor runtime performance. (Eg java, C#, Ruby, Python, lua, go, etc etc) Rust is a fine language. Personally I can’t wait to see what comes after it. I’m sure there’s even better ways to implement some of rust’s features. I hope someone out there is clever enough to figure them out.
- bgwalter 11mo ago
  [flagged]
  - aw1621107 11mo ago
    > Even in its own "memory safety" definition, which is the first result on Google, they criticize C instead of providing a proper definition: I'm not sure that page is intended to provide a definition of "memory safety" in the first place? It (and the following page) seem more intended to introduce safe/unsafe Rust and the boundaries between the two. It's also from the Rustinomicon, which states: > Unlike The Rust Programming Language, we will be assuming considerable prior knowledge. In particular, you should be comfortable with basic systems programming and Rust. So it's arguably unsurprising that a definition of memory safety would not be found there. My guess is that if you want a more precise definition you'd want to look at the Rust Reference (e.g., [0]) or in related areas. [0]: https://doc.rust-lang.org/reference/unsafety.html https://doc.rust-lang.org/reference/unsafety.html
  - Inityx 11mo ago
    I don't think materially contrasting yourself with your direct competition quite constitutes a "feud war"
    - bgwalter 11mo ago
      The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible. Which is a pity, because the language itself does not seem to be so bad.
      - josephg 11mo ago
        > Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through. I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response. > The Rust literature is poorly written compared to C and Ada I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing? I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library: https://doc.rust-lang.org/std/iter/trait.Iterator.html https://doc.rust-lang.org/std/iter/trait.Iterator.html Every function in that interface is well documented, with examples. Here's the equivalent for C++: https://en.cppreference.com/w/cpp/iterator/iterator.html https://en.cppreference.com/w/cpp/iterator/iterator.html Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far. So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here: http://www.lmdb.tech/doc/group__mdb.html http://www.lmdb.tech/doc/group__mdb.html In rust, any published crate automatically has a docs.rs/cratename link. Eg for serde's reference manual: https://docs.rs/serde/ https://docs.rs/serde/ And then for the "guide" style explanation they wrote a book: https://serde.rs/ https://serde.rs/ Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
  - josephg 11mo ago
    > That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad! I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety? The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing? When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.

beeflet 11mo ago

rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.

gpm 11mo ago
> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.
- petcat 11mo ago
  Yeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
  - kridsdale1 11mo ago
    It’s https://en.wikipedia.org/wiki/Bazel_(software) https://en.wikipedia.org/wiki/Bazel_(software)
- kridsdale1 11mo ago
  Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing. If I were to go to another company I’d promote using either of the above.
  - vlovich123 11mo ago
    What does Android do for Rust?
    - 11mo ago

tick_tock_tick 11mo ago

I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust. (doesn't mean it's not an improvement on C++)

ViewTrick1002 11mo ago
The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land. All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues because they are treated as bugs. It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.” https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22I-unsound%22 https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
selfmodruntime 11mo ago
This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
- tick_tock_tick 11mo ago
  Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b5ac5ef8f2928dcaab148fc911c12c5e https://play.rust-lang.org/?version=stable&mode=debug&editio... I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/25860
  - dwattttt 11mo ago
    Yes, that's an existing soundness hole in the compiler. You won't accidentally code it up yourself though. If the bar is "deliberately malicious code results in a segfault", get back to me when they fix memcpy(0x10000, 0x20000, 0x10); EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.

deleted 11mo ago

[deleted]

ActorNightly 11mo ago

Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative. That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.

kibwen 11mo ago
> That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does. Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is nontrivial.
- ActorNightly 11mo ago
  Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem. The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold. But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id. So you simply have a system of tracing where memory gets used. But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.
  - josephg 11mo ago
    So your claim is that sufficiently careful C is just as safe as rust? Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion: > Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.

jandrewrogers 11mo ago

It really depends on the type of software.

pjmlp 11mo ago

Nope, Rust compiler depends on LLVM and GCC (ongoing), both written in C++. Then there are enough industry standards that are defined for C and C++, where Rust isn't even visible.