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.

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

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.