Hacker News Reader

Comment by jraph | Hacker News Reader

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 convinced Rust is easier to write without the management of lifetimes in a short time span. However, what about long term maintenance, and application stability?

Rust with a GC probably has its uses (compiled language with strong error checking), but one has to know what ship they are boarding.

It also makes it quite closer to D, an "easier C++", compiled language with a GC.

(I'm saying this as someone who tried Rust, and mostly uses GC'd languages)

edit: thanks for the replies below. I hadn't though about this. I guess one should better read my message as "If you remove Rust's lifetime management, …"

View on HN

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.

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.

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.

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.

To be clear, I definitely wasn't talking about that.

Since you can't use the type system to guarantee that an object is destroyed, there are a few things in Rust that are a major pain to get working. Like passing a reference to a short-lived thread.

It's not that hard in my experience. You generally do it by using a guarded scope where the user provides a callback and doesn't manage the resource (like a thread) themselves.

Sure, if that works for you, it's easy. Stuff like crossbeam::scope only solves a subset of the problem, though. When that solution doesn't work for you, it's a pain.

Using a scope is, strictly speaking, less powerful and more annoying to work with than a more general system of linear types. It's like Go's defer, or C#'s using/IDisposable... they work in certain scenarios, but there's a percentage of the time where a lexical scope or function scope doesn't match the lifetime of your object, or can't match the lifetime of your object.

Yep, agreed.

> 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.

Rust has scoped threads for this use case. Generally this uses closures as opposed to lifetimes to "bound borrows from above" in a safe way.

Rust has crossbeam, but it is not a complete solution to the problem. Scoped threads were removed.

Would you mind elaborating?

It was removed from the standard library ages ago, but `crossbeam::scope` appears to still be there in the newest release of crossbeam and the git repo.

Using a scope for spawning threads is a solution to a narrow slice of a much larger problem.

> 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.

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

We were particularly interested in learnability for this study, which CAN be assessed in a study with students.

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 and https://arxiv.org/abs/1803.02796 I think)

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.

Ref-counting provides consistent performance - the costs are amortized smoothly over the operations. They aren't doing all this work for "purity".

Ref counting can also lead to memory leaks with circular references.

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.

> 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.

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.

> 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.

Can you use lifetimes for most objects, and use GC where it's "hard"? Like, canonical example with double linked lists.

You can do this in Rust today, with the standard library's reference counter

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>.

If you really do want to leak memory, Rc<T> is overcomplicated - just call `Box::leak` and throw away the output.

Rc<T> is the preferred way to introduce unintentional memory leaks.

Reply on news.ycombinator.com