On Monday, 2 November 2015 at 16:03:04 UTC, Andrei Alexandrescu wrote:

I don't follow Rust much, but my perception from following the trade news is that since launched it has scored a few victories (an OS project, a safe Doom implementation) but by and large the excitement has subsided after the pre-release excitement gave way to the post-1.0 certainty. The status seems to be - things aren't as great as they were cracked to be. Putting ownership front and center just makes things difficult, often for no good outcome.

The Rust devs have made a bunch of braindead design decisions that turned it from a promising systems language into a RAII tutorial for Rubyists. Finalizing those in 1.0 is what drove people away, including me.

That said, lifetime management is the one thing they did exactly right.

The key thing to observe here is that we already have lifetime semantics everywhere, it's just not always checked by the compiler. GC languages get around the issue by extending the unchecked lifetimes to infinity, the problem we have now is that this is incorrect without the GC. We don't need to add extra complexity or runtime overhead to do it right, just keep more information in the compiler and some syntax to talk about it.

In Rust, all object and reference lifetimes are tracked by the compiler, at no runtime cost. You can say "I'm only allocating objects that don't outlive me", and have it checked transitively for all references into those objects. You can say "my lifetime will be the shortest of the constructor arguments" or "my lifetime is independent of them".

Safe RC is almost trivial in Rust, they have both a thread-local `Rc<T>` and an atomic `Arc<T>` in the standard library. It's also very easy to write, say, lifetime-safe glib bindings, where the refcount semantics are documented externally.

It's almost always inferred away, there's no syntax overhead for the common case. Most people don't need to care beyond what they're already familiar with from the curly braces. In fact, neither `Rc<T>` nor `Arc<T>` have a single explicit lifetime annotation in their public API. It Just Works(tm), wrong usage will simply not compile.

For D, I believe this could be implemented without breaking any existing correct code, maybe with syntax like

    C!A foo(A: scope)(C!A c) { return c; }

or

    scope!A C foo(scope(A) C c) { return c; }

which with lifetime inference could safely be written as

   C foo(C c) { return c; }

Of course it gets tricky with mutability, raw pointers, non-static lifetimes etc, but Rust has been exploring the solution space for years now. It would be a shame to just ignore them, especially when people are already starting to do the same for C++: https://www.youtube.com/watch?v=hEx5DNLWGgA

_______________________________________________
Dlang-study mailing list
Dlang-study@puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study