Yep. And the struggle learning rust is that you sort of need to learn the borrow checker and lifetimes all at once. You can’t use rust at all without any of that stuff, and there’s a lot to learn before you feel productive! Even a year in to rust I can still throw things together a lot faster in javascript. That may always be true.

So I doubt rust will ever displace python and javascript for everyday app development. But it’s an excellent language for operating systems, game engines, databases, web browsers, IDEs and things like that where stability and performance matter more than cramming in ever more features.

The trick is to avoid long living references as much as possible. You need to unlearn the Java/JS/Python style where everything is a reference. In Rust you should default to value (fully owned) types and move semantics and use references for temporary borrows only. Think about cloning first when you need the data in more than one place, before considering references.

It is surprising how far you can get with that approach without ever writing a sigle lifetime annotation.

I’m nosy sure I agree. There definitely isn’t a “one-size-fits-all” to writing Rust, but I do think that falling back to a “error here? try .clone()” mentality ends up defeating the purpose.

Maybe what Rust needs is a “build a program with lots of allocations” and then “whittle down allocations with smart use of references” section of the book.

> Maybe what Rust needs is a “build a program with lots of allocations” and then “whittle down allocations with smart use of references” section of the book.

Rem acu tetigisti. This is what needs conveying. I think with Rust people are often speaking past one another. One person says "hey, you can't write EVERYTHING with meticulously-planned-out lifetimes, cows for every string, etc", and what they have in mind is a junior/novice programmer's first-time experience (or any combination thereof).

Whereas another person says "you can't clone everything everywhere, or wrap everything in a RefCell", and they are right about what they mean: that properly written software eventually, to be respectably efficient, needs to replace that kind of code with code that thoughtfully uses appropriate lifetimes to truly benefit from what Rust provides.

As usual, Wittgenstein is right, specifically in what he says in s.4 of his famous Buzzfeed article[0]: most so-called problems are merely confusions of language, where two people mistake an inconsistency in their use of signs for an inconsistency in their opinions. If they set it all out more fully and explicitly, I don't think there would be much disagreement at all about what's appropriate, at least among the 80% of reasonable people.

[0] https://www.buzzfeed.com/ludwigwittgenstein/fantastic-ways-t...

That was my first reaction too, but then I realized it's also value vs. reference types

i.e. Java doesn't have value types and that makes the syntax a lot cleaner vs. C++, and I'm pretty sure Kotlin must be the same

So you could still have ownership in a language with references only, and the syntax could be cleaner than Rust.

In fact I think there was a post about just that: Notes on a Smaller Rust https://without.boats/blog/notes-on-a-smaller-rust/

You very well may be able to, but any language that wants to position itself in C's niche won't get away with not having value types. When it comes to systems languages, it's a sad fact (for language designers, anyway) that elegance often loses to mechanical sympathy.

Kotlin has value classes. Here's a good overview of how they work in Kotlin: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

That document is a few years old now and was intended as a design document. But Value classes shipped with Kotlin 1.5. Apparently they are compatible with the project Valhalla value objects that will be added to the JVM at some point. So, this stuff is coming.

I had to look it up because even though I write Kotlin a lot, value classes are not something I have used at all. Looks useful but not that big of a deal and doesn't really solve a problem I have. Data classes and records (in Java) are a bigger deal IMHO.

In practice, the way you deal with immutability in Kotlin is to keep most of your data structures immutable by default unless they need to be mutable. E.g. there's a List and a MutableList interface. Most lists are immutable unless you create a MutableList. Same with val vs. var variables. Val variables can't be reassigned and you kind of use var only by exception when you really have to. The compiler will actually warn you if you do it without good reason. A data class with only vals can't be modified. Java is a bit more sloppy when it comes to mutability semantics. It has records now but all the fields have setters by default. It has var but no val assignments (you can use final to force this but few people do). And so on.

Semantically this is not as strong as what Rust does of course but it's good enough to make e.g. concurrency a lot easier. Mostly, if you avoid having a lot of mutable shared state, that becomes a lot easier.

You could imagine a Kotlin like language with much stronger semantics implementing borrow checking instead of garbage collection. It wouldn't be the same language of course but I don't think it needs to be very different. Using it would not be a massively different.

Kotlin doesn't really have value classes, those are wrappers around primitive types.

That is the thing with guest languages, they cannot invent something that the plaform doesn't support, and if they indeed come up with lots of boilerplate code to fake features, they risk to become incompatible when the platform actually does provide similar features with incompatible semantics.