[pjmlp]

If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust.

Hence all the Chapel, Swift, D, Linear Haskel, Ox, Idris2, Scala Capture Checking, Koka, and probably many others, efforts going on.

This is also noticeable among rustaceans, otherwise ergonomics for all the .clone() and related machinery, wouldn't be part of the 2026 roadmap.

[quotemstr]

If you want automated resource management, automate it. I'm really not convinced that Koka-style effects-for-everything are a win relative to just passing objects that own resources through parameters so they have actual values and explicit lifetimes.

[pjmlp]

I certainly do, which is why outside some hobby coding to try out new language features, as means to understand where Rust stands, I don't have any special use case where I would pick Rust instead of one of those languages.

For me its ideal use case, are places where any form of automated resource management is either not technically possible, or it is a waste of time trying to change mindsets.

[bigbadfeline]

> I don't have any special use case where I would pick Rust instead of one of those languages.

Rust isn't a language for a special case, Rust is universal. Those other languages are for special cases, you're simply a special case developer.

Picking a different language for each special case is the primary problem Rust solves, it's the problem of being a jack of all trades and a master of none.

>> If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust.

Can you write the proof down for us please? I'm curious, how do you prove that "for many scenarios" A+B is better than B+A?

The OP is about doing A in safe Rust, which isn't even an option for many of those other languages which are, at the very least, bootstrapped from unsafe code.

[pjmlp]

When every problem looks like a nail...

The proof is the amount of research that is ongoing for plenty of people that don't consider Rust as it stands today, the ultimate answer in programming languages, including people like Niko Matsakis.

Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?

[bigbadfeline]

> Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?

I don't deny the existence of special cases or the value of looking for better ergonomics even at the expense of university. However, at the moment Rust is the best option for practitioners who don't have enough time to juggle multiple languages.

[pjmlp]

Practitioners who don't have enough time to juggle multiple languages are on the wrong business.

[kibwen]

> it is better having automated resource management

Rust's ownership system is automated resource management. What you're asking for is dynamic lifetime determination, which Rust provides via types that opt out of the hierarchical single-ownership paradigm.

[pjmlp]

Nope, because it has plenty of manual hand holding to keep the compiler happy.

[kibwen]

Manual memory management requires the programmer to insert calls to free at specific points in the program. That's manual static lifetime determination. A traditional garbage collector uses runtime analysis to determine when it's safe to call free. That's automatic dynamic lifetime determination. What Rust does is automatic static lifetime determination. Designing your data structures such that they're acyclic is not what anyone means when they say "manual memory management".

[pjmlp]

Rust requires the programmer to manually design data structures and code algorithms in a way that doesn't trigger borrower checker compile errors.

There is nothing automatic out of it.

Write Rust code, compile error if done incorrectly, manually fix the data structure or algorithm root cause, loop.