| > 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. |
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?