6 ms·

The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust'

The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.

charcircuit 4y ago
Rust's memory model is even more familiar to C++ programmers who don't manage memory by hand because they have the same concepts of borrowing and lifetimes.
- est31 4y ago
  You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.
  - staunton 4y ago
    The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.
    - kitkat_new 4y ago
      not only the overhead, but even the semantics The difference is that the use of the smart pointers is checked of the compiler
    - ryandrake 4y ago
      I know this is an unpopular opinion but if you want to stick with C++, the solution to this, at least in my experience, is to stop doing things that let you shoot your foot off. C++ gives you every tool in the tool chest, and most of them are not safe. Stick to a safe subset and you've solved 90% of all those stereotypically C++ problems. I've got a pretty big C++ codebase for my hobby projects, sanded down, polished and perfected over the years without the usual corporate pressure to ship. The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. The simple key is to just stop doing these unnecessary things.
      - jjnoakes 4y ago
        The most recent example I debugged for a colleague was a container of callbacks, and one of them ended up changing the container while it was being iterated over. Nothing crazy, just no easy way that we were aware of to catch that kind of thing.
      - bbkane 4y ago
        Yes, but "just don't do that" doesn't scale to large teams with varying levels of experience and discipline. It sounds like you have rules that even you disobey on this project.
      - luuio 4y ago
        Everything you said is true. C++ gives you everything you need to be safe. But that's not the point. Rust makes it HARD (or very hard) to do things that are unsafe. It's not what C++ can or cannot do, it's not what Rust can or cannot do. It's what the Rust language and compiler opinionatedly encourage you to do and not to do. This is what's lacking in C++.
        blub 4y ago
        I think many people - me included - are complaining that it makes things hard period. Not in the sense of “rocket science” as this argument is sometimes smugly dismissed, but in the sense of extra friction which slows things down and decreases the pleasure of coding.
      - saagarjha 4y ago
        > The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? The problem with C++ is that all of these things don't look like unsafe operations, and people end up making mistakes with them that are not obvious.
  - kitkat_new 4y ago
    manually vs automatically (with more control about the how compared to other high level languages)
- xiphias2 4y ago
  I was just trying to find a modern C++ tutorial, but there's nothing comparable to the Rust Book on the internet. I think even now the best resource to learn C++ is to first learn C, then original C++, then all the modern memory management techniques, which is just crazy hard for a new programmer compared to just going through the Rust book 10 times (which is needed to get a deep understanding).
  - girvo 4y ago
    Professional C++ is the 1072 page book that taught me modern C++, for what it's worth. I have the physical copy. And even then I have gripes with some of it's contents! The Rust book is second to none, tbh, and I say this as someone who doesn't really write Rust.
    - pclmulqdq 4y ago
      1072 pages sounds like it's a little too thin to actually teach modern C++. I'll let you decide whether this is sarcasm - I could go either way.
    - thefourthchime 4y ago
      As someone who wrote C++ for 20 years, just don't. It's a horrible language(s). None of the codebases look the same, everyone uses different features or different versions of the language. Building is a nightmare, it takes forever to do anything. Run!
      - DoctorDabadedoo 4y ago
        Hey, but I have this single header only spaghetti-code library here, super easy to include in your package, should be a breeze to use! I'm with you, my sunken cost is 10 years, though.
      - girvo 4y ago
        100% agreed. Though the work I do pays very well!
zabzonk 4y ago
> for an experienced C++ programmer who is used to managing memory by hand nobody with an inch of nous does that anymore.
- turtledragonfly 4y ago
  I suppose it comes down to your definition of "by hand," but creating custom allocators for your application and arranging your memory layout carefully can still absolutely be a worthwhile endeavor. Especially when performance matters (eg: high frequency trading systems, video games, constrained embedded systems, and more), the improved locality that you can get from custom memory management can be worth it all on its own. For a good talk on this subject, see Lakos "Local Memory Allocators" presentation: * part 1: https://www.youtube.com/watch?v=nZNd5FjSquk https://www.youtube.com/watch?v=nZNd5FjSquk, part 2: https://www.youtube.com/watch?v=CFzuFNSpycI https://www.youtube.com/watch?v=CFzuFNSpycI
  - bluGill 4y ago
    Sure, but those are still carefully controlled places and the majority of code isn't doing it by hand. Not like some old code I've seen where there were many different code paths memory could get ownership transferred to.
- zabzonk 4y ago
  [flagged]
- jandrewrogers 4y ago
  Manually managing memory is idiomatic for performance engineering in C++. You don't always need to do it but it is definitely done.
cmrdporcupine 4y ago
when I started moving from C++ to Rust I found the easiest initial way to make sense of the borrow checker was to basically imagine that almost every argument passed in a function call was wrapped in a std::move.
- School-Cotton 4y ago
  every argument is passed by move, not just almost every. Types that implement Copy are still moved. Copy just means “the original value is still usable after move”.
  - cmrdporcupine 4y ago
    fair enough, but also the semantics of a Rust 'move' aren't identical to C++ std::move anyways. you can "get it back" after the function call, as it's a borrow, not a move. Makes me wonder out loud if the C++ community isn't going to add some kind of std::borrow/std::return_borrowed to the language. If that's even feasible with the type system and reference system as it is today.
blub 4y ago
Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas. Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust compiler. Unfortunately the Rust programming community has settled exactly on this kind of reference usage.
- kaba0 4y ago
  Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for way too long, but I never really understood the desire to use it for CRUD apps and the like. Sure, to each their own, but it is just an arguably bad choice. Even OSs could be written in managed languages - it’s not like it hasn’t been done before and they can just as well have escape hatches like Rust’s unsafe (hell, they are likely even safer if they are only used to manipulate “external heap”)
  - rstuart4133 4y ago
    All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem. I suspect it was just happy circumstance that a type system so strong it makes memory access compile time checkable is also strong enough to eliminate the overheads of GC. So they did that too. But the claim that all this tediousness is there to eliminate GC sort of misses the point - that's not the reason they introduced it. Rust's complex type system is a type of formal proof system that eliminates a lot of bugs at compile time. The "sum types" discussion above talks about another class of bugs it eliminates. Eliminating bugs at compile time is the point - not making memory allocation easier.

charcircuit 4y ago

Rust's memory model is even more familiar to C++ programmers who don't manage memory by hand because they have the same concepts of borrowing and lifetimes.

est31 4y ago
You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.
- staunton 4y ago
  The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.
  - kitkat_new 4y ago
    not only the overhead, but even the semantics The difference is that the use of the smart pointers is checked of the compiler
  - ryandrake 4y ago
    I know this is an unpopular opinion but if you want to stick with C++, the solution to this, at least in my experience, is to stop doing things that let you shoot your foot off. C++ gives you every tool in the tool chest, and most of them are not safe. Stick to a safe subset and you've solved 90% of all those stereotypically C++ problems. I've got a pretty big C++ codebase for my hobby projects, sanded down, polished and perfected over the years without the usual corporate pressure to ship. The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. The simple key is to just stop doing these unnecessary things.
    - jjnoakes 4y ago
      The most recent example I debugged for a colleague was a container of callbacks, and one of them ended up changing the container while it was being iterated over. Nothing crazy, just no easy way that we were aware of to catch that kind of thing.
    - bbkane 4y ago
      Yes, but "just don't do that" doesn't scale to large teams with varying levels of experience and discipline. It sounds like you have rules that even you disobey on this project.
    - luuio 4y ago
      Everything you said is true. C++ gives you everything you need to be safe. But that's not the point. Rust makes it HARD (or very hard) to do things that are unsafe. It's not what C++ can or cannot do, it's not what Rust can or cannot do. It's what the Rust language and compiler opinionatedly encourage you to do and not to do. This is what's lacking in C++.
      - blub 4y ago
        I think many people - me included - are complaining that it makes things hard period. Not in the sense of “rocket science” as this argument is sometimes smugly dismissed, but in the sense of extra friction which slows things down and decreases the pleasure of coding.
    - saagarjha 4y ago
      > The few times I run into memory corruption, a memory leak, a segfault, dereferencing a shit pointer, undefined behavior, and so on, its always, always because I'm doing something I shouldn't be doing. Like working with raw pointers or pointers to pointers to pointers, or traversing an array of bytes to do something there's already a library that does, or manually calling delete on something, or using reinterpret_cast<>, or using one of the many footguns C++ happily gives me. You've never used an out-of-bounds index? Accidentally used an object that was on the stack beyond the function call? Let an integer overflow? The problem with C++ is that all of these things don't look like unsafe operations, and people end up making mistakes with them that are not obvious.
- kitkat_new 4y ago
  manually vs automatically (with more control about the how compared to other high level languages)
xiphias2 4y ago
I was just trying to find a modern C++ tutorial, but there's nothing comparable to the Rust Book on the internet. I think even now the best resource to learn C++ is to first learn C, then original C++, then all the modern memory management techniques, which is just crazy hard for a new programmer compared to just going through the Rust book 10 times (which is needed to get a deep understanding).
- girvo 4y ago
  Professional C++ is the 1072 page book that taught me modern C++, for what it's worth. I have the physical copy. And even then I have gripes with some of it's contents! The Rust book is second to none, tbh, and I say this as someone who doesn't really write Rust.
  - pclmulqdq 4y ago
    1072 pages sounds like it's a little too thin to actually teach modern C++. I'll let you decide whether this is sarcasm - I could go either way.
  - thefourthchime 4y ago
    As someone who wrote C++ for 20 years, just don't. It's a horrible language(s). None of the codebases look the same, everyone uses different features or different versions of the language. Building is a nightmare, it takes forever to do anything. Run!
    - DoctorDabadedoo 4y ago
      Hey, but I have this single header only spaghetti-code library here, super easy to include in your package, should be a breeze to use! I'm with you, my sunken cost is 10 years, though.
    - girvo 4y ago
      100% agreed. Though the work I do pays very well!

zabzonk 4y ago

> for an experienced C++ programmer who is used to managing memory by hand nobody with an inch of nous does that anymore.

turtledragonfly 4y ago
I suppose it comes down to your definition of "by hand," but creating custom allocators for your application and arranging your memory layout carefully can still absolutely be a worthwhile endeavor. Especially when performance matters (eg: high frequency trading systems, video games, constrained embedded systems, and more), the improved locality that you can get from custom memory management can be worth it all on its own. For a good talk on this subject, see Lakos "Local Memory Allocators" presentation: * part 1: https://www.youtube.com/watch?v=nZNd5FjSquk https://www.youtube.com/watch?v=nZNd5FjSquk, part 2: https://www.youtube.com/watch?v=CFzuFNSpycI https://www.youtube.com/watch?v=CFzuFNSpycI
- bluGill 4y ago
  Sure, but those are still carefully controlled places and the majority of code isn't doing it by hand. Not like some old code I've seen where there were many different code paths memory could get ownership transferred to.
zabzonk 4y ago
[flagged]
jandrewrogers 4y ago
Manually managing memory is idiomatic for performance engineering in C++. You don't always need to do it but it is definitely done.

cmrdporcupine 4y ago

when I started moving from C++ to Rust I found the easiest initial way to make sense of the borrow checker was to basically imagine that almost every argument passed in a function call was wrapped in a std::move.

School-Cotton 4y ago
every argument is passed by move, not just almost every. Types that implement Copy are still moved. Copy just means “the original value is still usable after move”.
- cmrdporcupine 4y ago
  fair enough, but also the semantics of a Rust 'move' aren't identical to C++ std::move anyways. you can "get it back" after the function call, as it's a borrow, not a move. Makes me wonder out loud if the C++ community isn't going to add some kind of std::borrow/std::return_borrowed to the language. If that's even feasible with the type system and reference system as it is today.

blub 4y ago

Rust’s memory management is not hard, it’s just tedious. If programming in the future will mean annotating the crap out of everything then garbage-collected languages start to become attractive - see golang competing with Rust in unexpected areas. Perhaps the only hard part is storing and passing references everywhere, which may mean that one has to act like an automaton and patiently type their lifetimes to the Rust compiler. Unfortunately the Rust programming community has settled exactly on this kind of reference usage.

kaba0 4y ago
Well, a huge swath of the developer community did realize it like 20 years ago — the vast majority of applications can absolutely get away with a GC, and that’s the correct choice from the perspective of developer productivity and safety. Rust is a huge win for the small niches where the GC overhead is unacceptable, because it is completely novel in its memory safety, which is absolutely a must and was neglected for way too long, but I never really understood the desire to use it for CRUD apps and the like. Sure, to each their own, but it is just an arguably bad choice. Even OSs could be written in managed languages - it’s not like it hasn’t been done before and they can just as well have escape hatches like Rust’s unsafe (hell, they are likely even safer if they are only used to manipulate “external heap”)
- rstuart4133 4y ago
  All true, but I suspect the end goal Rust's type system wasn't to eliminate GC. It was "fearless concurrency". You can see this in languages that encourage multithreadeding and have a GC. In Go memory allocation is easy because of GC, but even so naively put working single threaded Go code in a multithreaded environment and it will likely segfault. GC doesn't solve the currency problem. I suspect it was just happy circumstance that a type system so strong it makes memory access compile time checkable is also strong enough to eliminate the overheads of GC. So they did that too. But the claim that all this tediousness is there to eliminate GC sort of misses the point - that's not the reason they introduced it. Rust's complex type system is a type of formal proof system that eliminates a lot of bugs at compile time. The "sum types" discussion above talks about another class of bugs it eliminates. Eliminating bugs at compile time is the point - not making memory allocation easier.