4 ms·

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or si

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or sigils and so on, but I also observe that: 1. High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. 2. I see sometimes C++ instructors making the same claims you do and then spending half of a lesson tracking down a memory mistake, (Casey Muratori) or in the same month a tweet from a game engine developer saying they don't really see the value of garbage collection and then tweeting about how they spent 48 hours tracking down a memory mistake. (of course, for a game engine that is what you have to do sometimes!) There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc.

jesse__ 4y ago
I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself. The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.
- jackmott42 4y ago
  I'm sure there is a ton of variance. I have done some Rust projects where I run into absolutely no safety complaints from Rust because it just isn't the kind of code that does anything the borrow checker cares about. For those development time ends up typically faster than C/C++ due to various syntax and tooling niceties. Other projects will really get into domains where you have to work hard to satisfy the borrow checker and it can slow you down a lot. In a real application you won't be writing lockless thread queues for a big % of the time. But then for a real application the compile times will start to weigh on you more. (Though, C++ does not always compile fast either unless some care is taken to be sure it does)
  - ttfkam 4y ago
    And you're running at least one static analysis tool and a linter on your C++ code too, right? You're not just deploying the C++ compiler output as-is, right? Those take time to run too and should absolutely be added to the compile time metrics when comparing against "cargo build".
    - jesse__ 4y ago
      On a personal project I run 2 metaprogramming passes, compile the entire project (~2m LoC) _twice_ and run the entire test suite in < 30s on a laptop from 2010. I don't run a linter because I hate them, and my metaprogramming passes do a bit of extra static checking clang doesn't. I occationally run extra static tools (valgrind et. al) but they're painfully slow and very rarely catch anything.
      - kaba0 4y ago
        Rust in incremental build mode is not slow at all, I really don’t see why people say so.
- kajaktum 4y ago
  >The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust. Do they have an equivalent API? Rust does have a hard time explaining very, very low level stuff that you'd have to do unsafe and various magicks. But once you get the unsafe details right, the consumer API for them tends to be extremely rigid and fool proof.
  - jnordwick 4y ago
    > Rust does have a hard time explaining very, very low level stuff A little odd for a supposed system langauge
    - kaba0 4y ago
      But it is just not true. Rust has a hard time writing algorithms where objects don’t have a singular owner. That’s all, it is not low level stuff. It for example has proper SIMD support, while the supposedly low level c doesn’t.
- pkulak 4y ago
  A lockless thread queue (not entirely sure what that would be, sorry; a queue in front of a pool?) seems like the kind of low-level library that could be written with liberal use of unsafe. No need to flagellate yourself on the altar of compile-time safety.
  - jesse__ 4y ago
    Then why would I use rust in the first place?
    - ColonelPhantom 4y ago
      So that you can write "primitives" such as a queue in unsafe, and assuming it is correct, it is not possible to introduce bugs from other code. Also, things like queues tend to be implemented in either the stdlib or a very popular library. So they are very well tested and likely to be widely reviewed.
- Yoric 4y ago
  My anecdotal experience is the opposite. I write code much faster in Rust than in C++. Part of it is thanks to the type system – fewer opportunities for dev errors means that I can produce code that is more concise, spends less time handling runtime errors because I can have static guarantees that they have already been handled somewhere, etc. Part of it is #[derive(...)], great documentation, Cargo and other QoL components of Rust.
  - jesse__ 4y ago
    Fair enough. I can imagine if you largely write code that plays nice with the compiler it could be faster. That just hasn't been my experience.
- deleted 4y ago
  [deleted]
- __jem 4y ago
  > The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust. Why is this your exercise you have in mind though? This is such a bad argument. Like, yes, if you work at doublylinkedlist.com where your entire job is writing a new linked list implementation every day of the week, Rust might be a bad choice. But that's not what any kind of commercial enterprise actually looks like. If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.
  - jesse__ 4y ago
    >> Why is this your exercise you have in mind though? That was an example I could point to where the code size difference between Rust and C or C++ is roughly 10x. I mentioned it to corroborate the claim that sometimes writing Rust is very verbose, on the order of ten times more. My point was not that average commercial codebases are largely dominated my these types of structures. My point was that my experience with Rust has been that the development slowdown is much more than 5%, as the OP suggested. >> If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time. And that's one reason we don't work together ;)
- mcronce 4y ago
  This is an ... interesting argument. "I can't write this 200LOC component of a large codebase in safe Rust, so what's the point in Rust?"
boris 4y ago
> There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc. I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint penalty), is it perhaps worth staying with C/C++ and spending more development time on testing/fuzzing?
- smolder 4y ago
  If you're willing to jump back to C++ to get around the borrow checker strictness, couldn't you just use Rust's unsafe block where you're sure it won't result in a bug? Is it harder to fuzz Rust? Honest question, because fuzzing is something I occasionally read about but am not practiced in.
  - duckerude 4y ago
    I've found it very easy to get started with fuzzing in Rust using cargo-fuzz. I didn't do anything very advanced, and my closest point of reference is testing Python with Hypothesis, but it did turn up bugs. Here's a Rust fuzzing story from yesterday: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-embarrassment-and-crashes/ https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-... It claims that Rust is particularly suitable for it because integer overflow panics in debug builds (and out of bounds indexing always panics), which sounds reasonable.
    - ttfkam 4y ago
      > And what did we screw up? Some legit stuff! It’s Rust code, so I am fairly confident none of the issues were security concerns, but they were definitely quality of implementation issues, and could have been used to at very least denial-of-service the minidump processor. This is so much better than the outcome would have been in any C or C++ project despite the many protestations of "just follow modern best practices" adherents. The author of minidump is no novice, is well versed in best practices in multiple languages including C++, was sure the code was solid, and still got spanked hard by the fuzzer. Denial of service outcomes aren't ideal, but they were likely fewer in number and are unambiguously better than security vulnerabilities.
3a2d29 4y ago
> High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. Safe rust would have caught. If you had to drop into unsafe to do what they did, the serious security bugs would still have happened.
- jackmott42 4y ago
  A fair point, though the few security issues in recent years I've looked at were not the kind of thing you would turn to unsafe rust for. But I've certainly not done a broad enough sampling to say what % of cases are like that.
  - 3a2d29 4y ago
    To be fair, I am sure Rust catches a fair amount (compared to C++ which would catch 0). I just think that phrasing rust has having 0 memory errors can be a tad inaccurate.
- ttfkam 4y ago
  Except when something goes wrong, you can typically focus all your attention on the unsafe blocks, which should be a very small portion of your codebase, if it exists at all. (Contrary to popular belief, unsafe Rust code is neither mandatory nor widespread.) By contrast and comparing apples to apples, your entire C or C++ codebase is the equivalent of one giant unsafe block. You can bring in 3rd party tools to perform some of the static analysis the Rust compiler does for you, but call it for what it is. By default, Rust is safe while C & C++ are not.
melissalobos 4y ago
> High quality teams like the Linux kernel team Which very notably does NOT use C++.
- csdreamer7 4y ago
  Nor does Postgres.
jandrewrogers 4y ago
> High quality teams like the Linux kernel team and PostgreSQL Neither of those code bases are C++, which significantly dilutes your point. A major benefit of modern C++ is that it is much safer than the language Linux and PostgreSQL are written in.
- Daishiman 4y ago
  Chromium _is_ written in C++, has some of the best coders and one of the best-tested codebases in the world. They're still finding zero-days based on exploits due to the language's failings. There's a reason Mozilla has decided that all parser code should be moved to Rust ASAP.
staticassertion 4y ago
The linux kernel is absolutely anything other than high quality lol

jesse__ 4y ago

I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself. The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

jackmott42 4y ago
I'm sure there is a ton of variance. I have done some Rust projects where I run into absolutely no safety complaints from Rust because it just isn't the kind of code that does anything the borrow checker cares about. For those development time ends up typically faster than C/C++ due to various syntax and tooling niceties. Other projects will really get into domains where you have to work hard to satisfy the borrow checker and it can slow you down a lot. In a real application you won't be writing lockless thread queues for a big % of the time. But then for a real application the compile times will start to weigh on you more. (Though, C++ does not always compile fast either unless some care is taken to be sure it does)
- ttfkam 4y ago
  And you're running at least one static analysis tool and a linter on your C++ code too, right? You're not just deploying the C++ compiler output as-is, right? Those take time to run too and should absolutely be added to the compile time metrics when comparing against "cargo build".
  - jesse__ 4y ago
    On a personal project I run 2 metaprogramming passes, compile the entire project (~2m LoC) _twice_ and run the entire test suite in < 30s on a laptop from 2010. I don't run a linter because I hate them, and my metaprogramming passes do a bit of extra static checking clang doesn't. I occationally run extra static tools (valgrind et. al) but they're painfully slow and very rarely catch anything.
    - kaba0 4y ago
      Rust in incremental build mode is not slow at all, I really don’t see why people say so.
kajaktum 4y ago
>The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust. Do they have an equivalent API? Rust does have a hard time explaining very, very low level stuff that you'd have to do unsafe and various magicks. But once you get the unsafe details right, the consumer API for them tends to be extremely rigid and fool proof.
- jnordwick 4y ago
  > Rust does have a hard time explaining very, very low level stuff A little odd for a supposed system langauge
  - kaba0 4y ago
    But it is just not true. Rust has a hard time writing algorithms where objects don’t have a singular owner. That’s all, it is not low level stuff. It for example has proper SIMD support, while the supposedly low level c doesn’t.
pkulak 4y ago
A lockless thread queue (not entirely sure what that would be, sorry; a queue in front of a pool?) seems like the kind of low-level library that could be written with liberal use of unsafe. No need to flagellate yourself on the altar of compile-time safety.
- jesse__ 4y ago
  Then why would I use rust in the first place?
  - ColonelPhantom 4y ago
    So that you can write "primitives" such as a queue in unsafe, and assuming it is correct, it is not possible to introduce bugs from other code. Also, things like queues tend to be implemented in either the stdlib or a very popular library. So they are very well tested and likely to be widely reviewed.
Yoric 4y ago
My anecdotal experience is the opposite. I write code much faster in Rust than in C++. Part of it is thanks to the type system – fewer opportunities for dev errors means that I can produce code that is more concise, spends less time handling runtime errors because I can have static guarantees that they have already been handled somewhere, etc. Part of it is #[derive(...)], great documentation, Cargo and other QoL components of Rust.
- jesse__ 4y ago
  Fair enough. I can imagine if you largely write code that plays nice with the compiler it could be faster. That just hasn't been my experience.
deleted 4y ago
[deleted]
__jem 4y ago
> The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust. Why is this your exercise you have in mind though? This is such a bad argument. Like, yes, if you work at doublylinkedlist.com where your entire job is writing a new linked list implementation every day of the week, Rust might be a bad choice. But that's not what any kind of commercial enterprise actually looks like. If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.
- jesse__ 4y ago
  >> Why is this your exercise you have in mind though? That was an example I could point to where the code size difference between Rust and C or C++ is roughly 10x. I mentioned it to corroborate the claim that sometimes writing Rust is very verbose, on the order of ten times more. My point was not that average commercial codebases are largely dominated my these types of structures. My point was that my experience with Rust has been that the development slowdown is much more than 5%, as the OP suggested. >> If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time. And that's one reason we don't work together ;)
mcronce 4y ago
This is an ... interesting argument. "I can't write this 200LOC component of a large codebase in safe Rust, so what's the point in Rust?"

boris 4y ago

> There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc. I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint penalty), is it perhaps worth staying with C/C++ and spending more development time on testing/fuzzing?

smolder 4y ago
If you're willing to jump back to C++ to get around the borrow checker strictness, couldn't you just use Rust's unsafe block where you're sure it won't result in a bug? Is it harder to fuzz Rust? Honest question, because fuzzing is something I occasionally read about but am not practiced in.
- duckerude 4y ago
  I've found it very easy to get started with fuzzing in Rust using cargo-fuzz. I didn't do anything very advanced, and my closest point of reference is testing Python with Hypothesis, but it did turn up bugs. Here's a Rust fuzzing story from yesterday: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-embarrassment-and-crashes/ https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-... It claims that Rust is particularly suitable for it because integer overflow panics in debug builds (and out of bounds indexing always panics), which sounds reasonable.
  - ttfkam 4y ago
    > And what did we screw up? Some legit stuff! It’s Rust code, so I am fairly confident none of the issues were security concerns, but they were definitely quality of implementation issues, and could have been used to at very least denial-of-service the minidump processor. This is so much better than the outcome would have been in any C or C++ project despite the many protestations of "just follow modern best practices" adherents. The author of minidump is no novice, is well versed in best practices in multiple languages including C++, was sure the code was solid, and still got spanked hard by the fuzzer. Denial of service outcomes aren't ideal, but they were likely fewer in number and are unambiguously better than security vulnerabilities.

3a2d29 4y ago

> High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. Safe rust would have caught. If you had to drop into unsafe to do what they did, the serious security bugs would still have happened.

jackmott42 4y ago
A fair point, though the few security issues in recent years I've looked at were not the kind of thing you would turn to unsafe rust for. But I've certainly not done a broad enough sampling to say what % of cases are like that.
- 3a2d29 4y ago
  To be fair, I am sure Rust catches a fair amount (compared to C++ which would catch 0). I just think that phrasing rust has having 0 memory errors can be a tad inaccurate.
ttfkam 4y ago
Except when something goes wrong, you can typically focus all your attention on the unsafe blocks, which should be a very small portion of your codebase, if it exists at all. (Contrary to popular belief, unsafe Rust code is neither mandatory nor widespread.) By contrast and comparing apples to apples, your entire C or C++ codebase is the equivalent of one giant unsafe block. You can bring in 3rd party tools to perform some of the static analysis the Rust compiler does for you, but call it for what it is. By default, Rust is safe while C & C++ are not.

melissalobos 4y ago

> High quality teams like the Linux kernel team Which very notably does NOT use C++.

csdreamer7 4y ago
Nor does Postgres.

jandrewrogers 4y ago

> High quality teams like the Linux kernel team and PostgreSQL Neither of those code bases are C++, which significantly dilutes your point. A major benefit of modern C++ is that it is much safer than the language Linux and PostgreSQL are written in.

Daishiman 4y ago
Chromium _is_ written in C++, has some of the best coders and one of the best-tested codebases in the world. They're still finding zero-days based on exploits due to the language's failings. There's a reason Mozilla has decided that all parser code should be moved to Rust ASAP.

staticassertion 4y ago

The linux kernel is absolutely anything other than high quality lol