6 ms·

For me personally Rust is not very interesting because it doesn't have a garbage collector. Manual memory management is just a pain in the ass and really not wo

For me personally Rust is not very interesting because it doesn't have a garbage collector. Manual memory management is just a pain in the ass and really not worth it for the vast majority of applications - games and realtime audio processing are an exception. Besides, if I don't want automatic memory management, I could also use Ada or Freepascal, who are both reasonably safe, though not generally as safe as Rust, and are mature and have a well-established toolchain.

foepys 10y ago
I have never done anything with Rust but I was under the impression that Rust's borrowing and ownership system made manually freeing memory more or less obsolete except for a few edge cases where the compiler isn't intelligent enough. Is this impression false?
- tatterdemalion 10y ago
  You are correct, you essentially never need to manually free memory.
- adrianN 10y ago
  Manual resource management in Rust is about as convenient as manual resource management in modern C++. That is, you don't really do any "manual" memory management at all in >90% of your code, it's all taken care of by RAII.
  - pjmlp 10y ago
    Yes, but with the added benefit not requiring external tooling to validate those RAII pattern are used correctly and forcing not so security savvy developers to actually use them.
    - kazagistar 10y ago
      So it's better, safer, but still manual memory management.
      - pjmlp 10y ago
        Not quite, because the rules are enforced by the compiler. In C++ the rules are enforced by optional tooling that most developers don't use. At CppCon 2015, only 1% of the audience acknowledged using such tools at Herb's talk about the core guidelines.
      - Manishearth 10y ago
        It's still automatic. You don't need to call free. The only difference is that you need to deal with whether or not things go on the heap, are refcounted, etc (but this decision is in the types, so you make it once and are done). Whether or not that's "manual" depends on your point of view. I consider it to be more along the lines of choosing guarantees.
- Sean1708 10y ago
  I don't think Rust even allows you to free your own memory without calling into libc, but then again I suppose you could say the same thing about C.
  - steveklabnik 10y ago
    Not on stable. On unstable you'd have a few options, similar to the ones you'd have for writing libc in the first place.
    - moosingin3space 10y ago
      Can't you use mem::drop to (effectively) deallocate memory before it goes out of scope? (I know this isn't quite the same thing as liballoc on nightly)
      - steveklabnik 10y ago
        That's true. Even though my parent said "free", I just assumed both sides of the equation :)
AsyncAwait 10y ago
The interesting thing about Rust, is that the manual memory management actually feels a lot like automatic memory management, moreover it applies to any resource[1], not just memory, (unlike in a GC'ed language) 1 - http://blog.skylight.io/rust-means-never-having-to-close-a-socket http://blog.skylight.io/rust-means-never-having-to-close-a-s...
dochtman 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. 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 ;)
ceronman 10y ago
I like to think about Rust's memory management as static/compile-time garbage collection, as opposed to the traditional dynamic/run-time garbage collection in languages such as Java. The process is mostly automatic because you don't have to manually free the memory you use like you do in C. The difference is that the moment when the memory must be freed is determined at compile time by Rust, while a dynamic GC has to determine this at runtime, which uses more resources but also ends up being easier to use.
- pif 10y ago
  > Rust's memory management as static/compile-time garbage collection I've never worked with Rust, so I may be horribly wrong. Based on what I understood, it's a more than what you say: resources are freed at a time determined by the source code, no random involved, thus you get GC and RAII at once.
p0nce 10y ago
> games and realtime audio processing are an exception. Not necessarily. D has a garbage collector and is used in games already such as Quantum Break. I do audio processing and had to limit GC usage in audio callbacks of course, but it was far from a showstopper.
gnuvince 10y ago
Rust does have automatic memory management; unlike language implementations that have a GC, Rust's compiler can do all that work at compile-time, rather than at run-time. Of course, this requires that the usage be analysable statically, which is why Rust has stricter rules.

foepys 10y ago

I have never done anything with Rust but I was under the impression that Rust's borrowing and ownership system made manually freeing memory more or less obsolete except for a few edge cases where the compiler isn't intelligent enough. Is this impression false?

tatterdemalion 10y ago
You are correct, you essentially never need to manually free memory.
adrianN 10y ago
Manual resource management in Rust is about as convenient as manual resource management in modern C++. That is, you don't really do any "manual" memory management at all in >90% of your code, it's all taken care of by RAII.
- pjmlp 10y ago
  Yes, but with the added benefit not requiring external tooling to validate those RAII pattern are used correctly and forcing not so security savvy developers to actually use them.
  - kazagistar 10y ago
    So it's better, safer, but still manual memory management.
    - pjmlp 10y ago
      Not quite, because the rules are enforced by the compiler. In C++ the rules are enforced by optional tooling that most developers don't use. At CppCon 2015, only 1% of the audience acknowledged using such tools at Herb's talk about the core guidelines.
    - Manishearth 10y ago
      It's still automatic. You don't need to call free. The only difference is that you need to deal with whether or not things go on the heap, are refcounted, etc (but this decision is in the types, so you make it once and are done). Whether or not that's "manual" depends on your point of view. I consider it to be more along the lines of choosing guarantees.
Sean1708 10y ago
I don't think Rust even allows you to free your own memory without calling into libc, but then again I suppose you could say the same thing about C.
- steveklabnik 10y ago
  Not on stable. On unstable you'd have a few options, similar to the ones you'd have for writing libc in the first place.
  - moosingin3space 10y ago
    Can't you use mem::drop to (effectively) deallocate memory before it goes out of scope? (I know this isn't quite the same thing as liballoc on nightly)
    - steveklabnik 10y ago
      That's true. Even though my parent said "free", I just assumed both sides of the equation :)

AsyncAwait 10y ago

The interesting thing about Rust, is that the manual memory management actually feels a lot like automatic memory management, moreover it applies to any resource[1], not just memory, (unlike in a GC'ed language) 1 - http://blog.skylight.io/rust-means-never-having-to-close-a-socket http://blog.skylight.io/rust-means-never-having-to-close-a-s...

dochtman 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. 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 ;)

ceronman 10y ago

I like to think about Rust's memory management as static/compile-time garbage collection, as opposed to the traditional dynamic/run-time garbage collection in languages such as Java. The process is mostly automatic because you don't have to manually free the memory you use like you do in C. The difference is that the moment when the memory must be freed is determined at compile time by Rust, while a dynamic GC has to determine this at runtime, which uses more resources but also ends up being easier to use.

pif 10y ago
> Rust's memory management as static/compile-time garbage collection I've never worked with Rust, so I may be horribly wrong. Based on what I understood, it's a more than what you say: resources are freed at a time determined by the source code, no random involved, thus you get GC and RAII at once.

p0nce 10y ago

> games and realtime audio processing are an exception. Not necessarily. D has a garbage collector and is used in games already such as Quantum Break. I do audio processing and had to limit GC usage in audio callbacks of course, but it was far from a showstopper.

gnuvince 10y ago

Rust does have automatic memory management; unlike language implementations that have a GC, Rust's compiler can do all that work at compile-time, rather than at run-time. Of course, this requires that the usage be analysable statically, which is why Rust has stricter rules.