6 ms·

To call Rust's approach "manual memory management", for me at least, feels just wrong. That phrase evokes the idea of C and C++, where you carefully have to do

To call Rust's approach "manual memory management", for me at least, feels just wrong. That phrase evokes the idea of C and C++, where you carefully have to do a lot of work and keep close track of your memory management strategy to make sure you don't make any mistakes. In Rust, on the other hand, once you gain some experience at least, you don't think about memory management that much, until the compiler tells you how your strategy is wrong, and then you adapt your strategy to cope with it. This is very different from C/C++, where typically your program just crash at random when you get it wrong, and then you have to figure out where or how it's wrong. And yes, mature and well-established are nice features. On the other hand, I can tell you that modern tooling like cargo, even if not quite as mature and well-established, can also bring large productivity benefits with it. Dependency tracking and build systems are largely a solved problem in Rust.

jhasse 10y ago
> To call Rust's approach "manual memory management", for me at least, feels just wrong. That phrase evokes the idea of C and C++, where you carefully have to do a lot of work and keep close track of your memory management strategy to make sure you don't make any mistakes. C != C++, because in the latter you can use smart pointers - just like in Rust. > Dependency tracking and build systems are largely a solved problem in Rust. I wouldn't say so, especially since incremental compilation is still an experimental feature only available in nighty. And tracking objects dependencies across crates isn't even possible ATM.
- pjmlp 10y ago
  > C != C++, because in the latter you can use smart pointers - just like in Rust. While that is what good C++ programmers do, you cannot (sadly) prevent others to program just like in C.
  - jhasse 10y ago
    But I can't prevent others to use unsafe in Rust either ;)
    - pjmlp 10y ago
      I can grep for unsafe, for C and C++ I need the help of a static analyzer.
      - jhasse 10y ago
        If you just grep, you'll get false-positives like // We don't need unsafe here or print!("This is NOT unsafe"); So you'd want a static analyzer anyway.
        lmm 10y ago
        Perhaps a "static analyzer" in some sense, but it would be a trivial one. It wouldn't have to do the sophisticated analysis necessary to tell whether someone is e.g. using a moved value in C++. C++ programmers love to claim that there's a simple set of rules that everyone can follow to write code that's just as safe as Rust, but somehow whenever you ask them to actually write down those rules it turns out they can't.
        pjmlp 10y ago
        Sure, but that is what sed is for, removing comments. With Rust, or any other systems safe language for that matter, I can be assured that any code that violates the type system is contained in such blocks. In C or C++ written in C style, any string, vector, function call with out parameters, data structure manipulation can be hiding unsafe code. It is quite different just having to review some well defined sections than the whole program. However I do concede all of this fails flat when using third party binary libraries. I do enjoy using C++ since C++ARM days, already back then many of the modern C++ practices were possible after templates got added into the language, yet enterprise "C compiled with C++ compiler" code is the norm in many companies. Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly.
        moosingin3space 10y ago
        > Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly. Even though it's controversial, I think this is why it's a good thing Rust can't #include a C header directly (requiring bindgen to make a crate). The community has put work into making safe abstractions over the raw C.
- dochtman 10y ago
  C++ smart pointers won't prevent you from making the mistake that the OP was about: giving out a reference to an interior object without limiting the lifetime for that reference. I meant dependency tracking in terms of which libraries you need what versions of. Incremental compilation as a project in nightly is about improving compile times only, not about any functional change in build system/project management tooling. In this context, I'm not sure what you mean by tracking objects across dependencies.
  - jhasse 10y ago
    > Incremental compilation as a project in nightly is about improving compile times only, not about any functional change in build system/project management tooling. Keeping compile times to a minimum is an essential task of a build system for me. That's why I wouldn't say that "build systems are a solved problem" in Rust. > In this context, I'm not sure what you mean by tracking objects across dependencies. When I make a change in one file in a crate, this triggers a complete rebuild of all the dependent crates.
    - Manishearth 10y ago
      > When I make a change in one file in a crate, this triggers a complete rebuild of all the dependent crates. That's the same thing as incremental compilation.
      - jhasse 10y ago
        Well the difference is that the implementation of incremental builds in Rust nightly doesn't handle this case yet AFAIK.
        Manishearth 10y ago
        Oh, I see what you mean. I think it's planned.
- naasking 10y ago
  > C != C++, because in the latter you can use smart pointers - just like in Rust. That's an overstatement. You can use smart pointers in C++, but they're not at all equivalent to the usability of Rust's pointer abstractions.
  - jhasse 10y ago
    But they are equivalent to smart pointers in Rust. For example even in Rust using std::sync::Arc can result in memory leaks just like in C++ with std::shared_ptr.
    - steveklabnik 10y ago
      They're not equivalent, though they are similar. For example, Rust is able to have the Rc/Arc split, allowing for increased performance in single-threaded code. You can't do that with shared_ptr, or at least, not in a way that's checked like in Rust.
    - naasking 10y ago
      They are not equivalent. For one, the Rust compiler checks that the references are properly initialized, passed around and dropped. C++ makes no such guarantees.
kazagistar 10y ago
Just because it gets easier over time doesn't mean memory management is not manual. You still have to think about ownership, stack vs heap, when things are freed, clone vs move, and so on. While the compiler will catch if you mess up, every piece you consider I'm a design has a mental cost. I would argue that memory management in Rust is a much smaller burden then you might expect, bit it's still there.
- jmcomets 10y ago
  > You still have to think about ownership, stack vs heap, when things are freed, clone vs move, and so on. Some responses: - ownership / clone vs move = Valid concern in any imperative language. - stack vs heap / when things are freed = Nope. Things are freed when you no longer use them. Are you upcasting to a parent "class"? Use `Box::new(value)`. Otherwise there's no cognitive overhead. I come from C++ and I've written quite a lot of Python. Rust feels a lot more like a typed Python than C++, memory-wise.

jhasse 10y ago

> To call Rust's approach "manual memory management", for me at least, feels just wrong. That phrase evokes the idea of C and C++, where you carefully have to do a lot of work and keep close track of your memory management strategy to make sure you don't make any mistakes. C != C++, because in the latter you can use smart pointers - just like in Rust. > Dependency tracking and build systems are largely a solved problem in Rust. I wouldn't say so, especially since incremental compilation is still an experimental feature only available in nighty. And tracking objects dependencies across crates isn't even possible ATM.

pjmlp 10y ago
> C != C++, because in the latter you can use smart pointers - just like in Rust. While that is what good C++ programmers do, you cannot (sadly) prevent others to program just like in C.
- jhasse 10y ago
  But I can't prevent others to use unsafe in Rust either ;)
  - pjmlp 10y ago
    I can grep for unsafe, for C and C++ I need the help of a static analyzer.
    - jhasse 10y ago
      If you just grep, you'll get false-positives like // We don't need unsafe here or print!("This is NOT unsafe"); So you'd want a static analyzer anyway.
      - lmm 10y ago
        Perhaps a "static analyzer" in some sense, but it would be a trivial one. It wouldn't have to do the sophisticated analysis necessary to tell whether someone is e.g. using a moved value in C++. C++ programmers love to claim that there's a simple set of rules that everyone can follow to write code that's just as safe as Rust, but somehow whenever you ask them to actually write down those rules it turns out they can't.
      - pjmlp 10y ago
        Sure, but that is what sed is for, removing comments. With Rust, or any other systems safe language for that matter, I can be assured that any code that violates the type system is contained in such blocks. In C or C++ written in C style, any string, vector, function call with out parameters, data structure manipulation can be hiding unsafe code. It is quite different just having to review some well defined sections than the whole program. However I do concede all of this fails flat when using third party binary libraries. I do enjoy using C++ since C++ARM days, already back then many of the modern C++ practices were possible after templates got added into the language, yet enterprise "C compiled with C++ compiler" code is the norm in many companies. Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly.
        moosingin3space 10y ago
        > Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly. Even though it's controversial, I think this is why it's a good thing Rust can't #include a C header directly (requiring bindgen to make a crate). The community has put work into making safe abstractions over the raw C.
dochtman 10y ago
C++ smart pointers won't prevent you from making the mistake that the OP was about: giving out a reference to an interior object without limiting the lifetime for that reference. I meant dependency tracking in terms of which libraries you need what versions of. Incremental compilation as a project in nightly is about improving compile times only, not about any functional change in build system/project management tooling. In this context, I'm not sure what you mean by tracking objects across dependencies.
- jhasse 10y ago
  > Incremental compilation as a project in nightly is about improving compile times only, not about any functional change in build system/project management tooling. Keeping compile times to a minimum is an essential task of a build system for me. That's why I wouldn't say that "build systems are a solved problem" in Rust. > In this context, I'm not sure what you mean by tracking objects across dependencies. When I make a change in one file in a crate, this triggers a complete rebuild of all the dependent crates.
  - Manishearth 10y ago
    > When I make a change in one file in a crate, this triggers a complete rebuild of all the dependent crates. That's the same thing as incremental compilation.
    - jhasse 10y ago
      Well the difference is that the implementation of incremental builds in Rust nightly doesn't handle this case yet AFAIK.
      - Manishearth 10y ago
        Oh, I see what you mean. I think it's planned.
naasking 10y ago
> C != C++, because in the latter you can use smart pointers - just like in Rust. That's an overstatement. You can use smart pointers in C++, but they're not at all equivalent to the usability of Rust's pointer abstractions.
- jhasse 10y ago
  But they are equivalent to smart pointers in Rust. For example even in Rust using std::sync::Arc can result in memory leaks just like in C++ with std::shared_ptr.
  - steveklabnik 10y ago
    They're not equivalent, though they are similar. For example, Rust is able to have the Rc/Arc split, allowing for increased performance in single-threaded code. You can't do that with shared_ptr, or at least, not in a way that's checked like in Rust.
  - naasking 10y ago
    They are not equivalent. For one, the Rust compiler checks that the references are properly initialized, passed around and dropped. C++ makes no such guarantees.

kazagistar 10y ago

Just because it gets easier over time doesn't mean memory management is not manual. You still have to think about ownership, stack vs heap, when things are freed, clone vs move, and so on. While the compiler will catch if you mess up, every piece you consider I'm a design has a mental cost. I would argue that memory management in Rust is a much smaller burden then you might expect, bit it's still there.

jmcomets 10y ago
> You still have to think about ownership, stack vs heap, when things are freed, clone vs move, and so on. Some responses: - ownership / clone vs move = Valid concern in any imperative language. - stack vs heap / when things are freed = Nope. Things are freed when you no longer use them. Are you upcasting to a parent "class"? Use `Box::new(value)`. Otherwise there's no cognitive overhead. I come from C++ and I've written quite a lot of Python. Rust feels a lot more like a typed Python than C++, memory-wise.