While I welcome the effort going into improving the lifetimes experience in Rust, this also kind of reflects that the approach being taken by other languages, meaning keeping automatic memory management by default, and only enough affine/linear typing support for when performace really, really matters, is a more productive approach.
Examples of that approach, D, Swift, Chapel, Linear Haskell, OCaml Effects.
The changes on the article, while welcomed in the context of Rust typesystem, will make being aware of all borrow check rules even more complex, and back into language lawyers kind of C++ developer experience, unless backed up by IDE tooling, on when to write what suggestions.
> Unfortunately, most people seem to have taken the wrong lesson from Rust. They see all of this business with lifetimes and ownership as a dirty mess that Rust has had to adopt because it wanted to avoid garbage collection. But this is completely backwards! Rust adopted rules around shared mutable state and this enabled it to avoid garbage collection. These rules are a good idea regardless
Ownership and borrowing are very useful regardless of performance and memory management.
They help to reason about the program, enabling local reasoning instead of global. When your function gets an owned object or exclusive reference, you know nothing else will mutate it (and you get that without resorting to purity/immutability). You don't need defensive copies.
In your methods you can return temporary references to internal objects, and you don't have to worry that users will keep them too long (such as use a handle to a resource after you close/delete the resource).
There are many useful patterns that can be expressed with control over sharing, copying, and mutability, and memory management is just one of them.
Whether that’s the sweet spot really depends on what your goal is.
The languages that you mention are several times slower than Rust for non-IO bound stuff (in the computer language benchmarks game). If this speed penalty matters for what you are doing, then idiomatic Rust can be much better than Haskell or OCaml code tuned for performance.
And when it comes to Linear Haskell specifically, GHC does not use linear types for performance optimization. If this has changed recently, I’d be thankful for a source to read more.
What I can tell you is that there are tasks that I cannot do in Python because my work would take 70 times longer to finish than if I did it in Rust. And that’s not a delay on the order of seconds but on the order of weeks.
Spot on, Rust is only for very special use cases, where the only viable alternative would be raw C, or C++ with its wrong defaults, instead of any other compiled language.
Between Python and Rust there is a myriad of compiled languages to chose from, no need for Rust for those 70x improvement.
Yet, to come back to the microbenchmarks reasoning, many folks will still pick up Python's productivity over Rust's 70x speed improvement.
You are a reasonable person. I don’t know why you are arguing that one approach fits every use case. In your earlier post above, you declared a sweet spot that fits everyone. All I’m saying is that the sweet spot depends on the application.
If Python’s productivity made up for its problems, then the OS you’re using (kernel + significant parts of userland) would be written in Python, too. But it isn’t, because sometimes its speed penalty is prohibitive. This is not a controversial statement. And the OS is not a “very special use case.”
I am typing this from an OS that is mostly written in Java, with only enough C, C++ and Rust for when it matters.
Rust will probably never replace Java on this OS, or Kotlin, for the applications on Play Store, that aren't a game engine. It isn't even officially supported on the NDK.
Just like on my fruity devices, it is Swift, with non copyable types that will be used for systems services and firmware, not Rust.
This is the kind of sweet spot I am talking about.
Python only came into the picture, as an example of people that don't look into performance charts before picking their tools.
And if Python community was half as serious as the Lisp community in JIT/AOT toolchains, who knows, maybe some would be crazy enough to create a Python Machine.
> it is Swift, with non copyable types that will be used for systems services and firmware
When you mention firmware, do you know of examples where Swift is used for this, or is this an aspiration? Are you talking about Swift for Arduino maybe, or do you have something else in mind?
We'll see how well it works for those languages. I have strong doubts that it'll be very usable in practice in for example Swift. That's because the boundary between "reference-anywhere" and aliasable-xor-mutable is notoriously problematic to cross, and when your entire ecosystem is "reference-anywhere" (e.g. Swift's core collections), your aliasable-xor-mutable world becomes very limited, to the point where most programmers won't even bother.
That is the point anyway, this is black level 10 dan stuff for many codebases, only to be used when it really matters, no need to write everything like this.
The problem being that most of the time you can't really use it even when it really matters, because the rest of the ecosystem doesn't. “when it really matters, and you have the freedom to do it” is not as good as “when it really matters”.
Examples of that approach, D, Swift, Chapel, Linear Haskell, OCaml Effects.
The changes on the article, while welcomed in the context of Rust typesystem, will make being aware of all borrow check rules even more complex, and back into language lawyers kind of C++ developer experience, unless backed up by IDE tooling, on when to write what suggestions.