Rust as a High Level Language

[shelby3]

@llogiq

I [wrote]( Rust code for three months before having to write (let alone think about) a single lifetime annotation. I knew they were there, but I was productive without them anyway. Lifetime elision is awesome.

And thats why I expected the most frequent case of borrowing would be implicit so I don't have to annotate my code until I need it, but it isn't because of some mostly subjective choice to be more explicit by default. I thought the slogan was "zero cost" abstractions.

Edit: especially I shouldn't be forced to annotate pure functions. Obviously they can safely borrow.

@llogiq

Second, I really think that Rust's model is superior to both pure functional languages (because sometimes mutation is darn useful)

I've read that fully optimized immutable functional programming can only get to within a log factor performance of imperative mutable programming. And as you allude, sometimes it is much more difficult to structure the same algorithm in an immutable way.

@llogiq

Also note that iterator invalidation is just one symptom of the problem of mutability + aliasing. So even with functors, you still cannot be sure that other code you are calling messes with your data. Ok, you can make everything immutable and rely on GC, but that won't help you if one unsafePerformIO you didn't know of breaks everything.

I think it is often more useful to think in higher-level terms. Depending on what the use case and design is, there may be very elegant ways to provide the necessary guarantees rather than falling back to a finely grained bottom-up approach to a memory ownership model. The fine grained approach intertwines a lot of minute invariant declarations and inferrants. Sometimes there may be a higher level design solution. That is why I am saying that Rust's memory ownership model everywhere is not likely to be optimum. It will hopefully have some very well matched use cases.