3 ms·

I don't know where you'd get the idea that everyone who knows modern C++ prefers Rust. I'm not the only one who knows how to use modern C++ and usually goes wit

I don't know where you'd get the idea that everyone who knows modern C++ prefers Rust. I'm not the only one who knows how to use modern C++ and usually goes with Rust instead. In my opinion, modern C++ is less safe than classic C++, because it adds more ways to get use after free (e.g. lambdas). Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.

ncmncm 8y ago
The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. Are they now of mainly theoretical importance? I can't answer that definitively, but I can say it has been many years since I had a bug in C++ code that using Rust, instead, would have prevented. My bugs are specification bugs. Memory bugs just are not on the radar. But coding Rust takes me enough longer than C++ that I can't justify it. Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust. And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.
- pcwalton 8y ago
  > The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style. > Are they now of mainly theoretical importance? No.
- caseymarquis 8y ago
  Why would someone use Rust over Java/Kotlin/Scala/C#/F#? Macros would be a small improvement, but at the price of reflection (JVM has Clojure for this). If I was using one of those languages, I don't really think the performance gain from moving to Rust would outweigh the added mental overhead, cost of learning new libraries, or developer scarcity. I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.
jandrewrogers 8y ago
I have many years of experience with large-scale C++ projects at multiple companies, and have written >100kLoC of modern C++ personally. I've seen thousands of bugs come and go. Memory safety bugs are vanishingly rare in the code bases I've worked on, and in all those years the handful that I recall were created by people new to C++ (usually cross-trained Java programmers). It is difficult to create memory safety bugs in idiomatic modern C++, and achieving this has no meaningful overhead. Memory safety is important but Rust proponents have constructed a bit of a straw man with respect to modern C++. Use that argument against C or classic C++, where it has more relevance. At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do. The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice. There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.
- pcwalton 8y ago
  I also have many years of experience with large-scale C++, and my experience is very different from yours. The difference, I suspect, is that browsers are actively attacked, via fuzzers and so forth. When you have contests like Pwn2Own targeting you, it's very eye-opening how many memory safety bugs you are shipping, even in fancy modern C++. (I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)

ncmncm 8y ago

The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. Are they now of mainly theoretical importance? I can't answer that definitively, but I can say it has been many years since I had a bug in C++ code that using Rust, instead, would have prevented. My bugs are specification bugs. Memory bugs just are not on the radar. But coding Rust takes me enough longer than C++ that I can't justify it. Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust. And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.

pcwalton 8y ago
> The relevant question is the degree to which memory errors remain a significant source of bugs in modern C++ code. That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style. > Are they now of mainly theoretical importance? No.
caseymarquis 8y ago
Why would someone use Rust over Java/Kotlin/Scala/C#/F#? Macros would be a small improvement, but at the price of reflection (JVM has Clojure for this). If I was using one of those languages, I don't really think the performance gain from moving to Rust would outweigh the added mental overhead, cost of learning new libraries, or developer scarcity. I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.

jandrewrogers 8y ago

I have many years of experience with large-scale C++ projects at multiple companies, and have written >100kLoC of modern C++ personally. I've seen thousands of bugs come and go. Memory safety bugs are vanishingly rare in the code bases I've worked on, and in all those years the handful that I recall were created by people new to C++ (usually cross-trained Java programmers). It is difficult to create memory safety bugs in idiomatic modern C++, and achieving this has no meaningful overhead. Memory safety is important but Rust proponents have constructed a bit of a straw man with respect to modern C++. Use that argument against C or classic C++, where it has more relevance. At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do. The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice. There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.

pcwalton 8y ago
I also have many years of experience with large-scale C++, and my experience is very different from yours. The difference, I suspect, is that browsers are actively attacked, via fuzzers and so forth. When you have contests like Pwn2Own targeting you, it's very eye-opening how many memory safety bugs you are shipping, even in fancy modern C++. (I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)