5 ms·

If you add a garbage collector to Rust, you neutralize one of its strength: the controlled lifetime of objects. You also make memory leaks easier. I'm convince

• torginus 5y ago
  Tbh, I'm not sure about this GC-purism. I've encountered tons of high-end C++ that's absolutely full of smart pointers, which is a form of GC. Rust has Rc<> and Arc<> as well. Having a a ref-counted GC instead of a tracing one doesn't seem like a step up in 'purity' to me.
  • jeremyjh 5y ago
    Ref-counting provides consistent performance - the costs are amortized smoothly over the operations. They aren't doing all this work for "purity".
    • louthy 5y ago
      Ref counting can also lead to memory leaks with circular references.
      • deleted 5y ago
        [deleted]
    • bjourne 5y ago
      Performance of ref-counting is proportional to the size of the dead objects. Performance of tracing gc is proportional to the size of the alive objects. In other words, there are many real-world situations in which ref-counting pauses are much longer than tracing gc pauses.
• rwmj 5y ago
  Garbage collection and controlled object lifetimes are important and orthogonal concerns. You can have both at the same time. C# for instance lets you add a Dispose() method for the times when you want to free the resources now. There are even ways to ensure statically that objects aren't used after the close/dispose is called. (Of which I would find the paper, but my google-fu is failing me right now ... https://okmij.org/ftp/Haskell/regions.html https://okmij.org/ftp/Haskell/regions.html and https://arxiv.org/abs/1803.02796 https://arxiv.org/abs/1803.02796 I think)
  • deleted 5y ago
    [deleted]
• klodolph 5y ago
  Rust’s type system doesn’t guarantee that object lifetimes are bounded from above (guaranteed to be destroyed), just that they are bounded from below (guaranteed to exist when used). This is why you have stuff like crossbeam—elaborate workarounds for a lack of linear types in Rust.
  • deleted 5y ago
    [deleted]
  • staticassertion 5y ago
    It doesn't guarantee it under all circumstances, like if your computer shuts off obviously destructors don't get called. But you can rely on the behavior to be deterministic.
    • klodolph 5y ago
      You can rely on the behavior to be deterministic, but the Rust type system provides no way on relying on this determinism. For example, if you have a stack variable and pass a reference to a short-lived thread, Rust will just throw an error, because there is no way for Rust to prove that the lifetime of the borrow is short enough (bounded from above) because Rust does not have linear types. I want it to be exactly clear what I'm saying... While you (the programmer) may understand when an object is destroyed, and Rust (the compiler) will agree with you, that information is not present in the type system and you cannot use it in your programs. In this aspect, Rust has the same problems as C++... but where C++ still lets you write code, Rust will just throw an error and force you to use "unsafe" here.
      • staticassertion 5y ago
        Yes, that's correct. I just want to be clear that it's not like destructors in rust are unreliable in the way that finalizers are in Java.
        • klodolph 5y ago
• IshKebab 5y ago
  > I'm convinced Rust is easier to write without the management of lifetimes in a short time span. Yeah that's the problem with all these studies that use students writing new code for a few hours. 99% of coding isn't like that - it's reading other people's code (including code you wrote ages ago and can't remember), trying to figure out how it works, following complex call chains, debugging etc. If you only look at Advent of Code type problems you'll come up with all sorts of strange conclusions, like static types don't make a difference, comments aren't useful at all, it doesn't matter if you exclusively use single character variable names, goto is totally harmless, etc. etc. Though in this particular case I guess they didn't have much choice because there are no existing large programs written using Bronze.
  • Farmadupe 5y ago
    I'm not 100% sure, but I think the OP was talking about the overhead of lifetime management for objects that don't live for a very long time. Or maybe objects that don't have "interesting" lives. One example in my head individual strings that need to be constructed dynamically but live for the lifetime of the application (better to leak it with Box::leak or lazy_static! than pollute all code with lifetimes) Another is writing in lifetimes for single purpose objects that live on the stack and might only ever get passed by ref into a single function and then get destroyed soon after. Lifetimes are super important in rust and are a core part of the language, but in such degenerate cases they take up a lot of programmer effort for little benefit. In my head a "automatic" solution such as GC /could/ have a home in the language. Perhaps this would make rust a slightly better fit for really complex monolithic GUI apps (word processing, spreadsheets, CAD) where full GC would be performance-onerous but data lifetimes would be too complex for rust's strictly ordered lifetime concept
  • mcoblenz 5y ago
    We were particularly interested in learnability for this study, which CAN be assessed in a study with students.
• petre 5y ago
  > It also makes it quite closer to D, an "easier C++", compiled language with a GC. That's exactly why I loved D over C++ and Rust and had the feeling that I was not fighthing the compiler from day one: the GC, auto types, lack of annoying C preprocessor.
  • jraph 5y ago
    D also has the good characteristic of not needing to download the entire Earth and compile half of it before starting a project. You just apt install ldc2 or apt install gdc and there you go (pun not intended). This actually made me chose D over Rust for my last project.
    • p0nce 5y ago
      > those who [used the GC] required only about a third as much time (4 hours vs. 12 hours). This makes me happy to use D instead of Rust. D has a @safe subset.
• KptMarchewa 5y ago
  Can you use lifetimes for most objects, and use GC where it's "hard"? Like, canonical example with double linked lists.
  • rtoway 5y ago
    You can do this in Rust today, with the standard library's reference counter
    • klodolph 5y ago
      Also, one of the easiest ways to leak memory in Rust. My understanding is that substructural typing systems are just not quite powerful enough to represent the semantics of double-linked lists, but I don't understand the math myself. Obviously it won't leak memory if you do it correctly, but Rust will happily let you leak memory in an Rc<T>.
      • ThomasWinwood 5y ago
        If you really do want to leak memory, Rc<T> is overcomplicated - just call `Box::leak` and throw away the output.
        • klodolph 5y ago
          Rc<T> is the preferred way to introduce unintentional memory leaks.