Hi, Thanks for all the effort and thought put into designing and developing Rust.
Caveats:
I'm a non-CS/non-programmer whose arrived at Rust via (mainly) SAS, R and Ruby. I've committed some effort to Rust because Rust is to the CPU/memory what Rails is to Ruby - a DSL that gets you 80% of the way with 20% of the effort.
In that context: I thought some here might be interested in language features others find compelling.
This is a 6 part breakdown on the Ruby features a Crystal developer (Ary Borenszweig) finds attractive - actually the articulation of what is considered intuitive is what I found most interesting:
For clarity, I'm not a CS-languages person, just a user. So I can't really offer any further insights, I just thought this might be of interest to people who, like Ari, obviously have given serious thought to language functionality.
I think all those features can be summarized in "do more things implicitly". Rust chooses to be more explicit by design, so they wouldn't really fit in the language. Also, Ruby features may seem nice if you're writing code, but they may easily become a burden for the reader.
I completely agree with @SkiFire13. Some of those features are a good fit for Ruby and bad for Rust (e.g. automatically-buffered IO), some are bad fit even for Ruby IMO (e.g. redefine a keyword). The only feature I think may provide value for Rust is blocks, and I think the ControlFlow enum is enough here, at least in the meantime.
A bunch of them look like they're assuming a dynamic language, too. For example, I agree that in a unityped language (aka one without useful static checking) that it's better for == to do something reasonable by default than something misleading. But in Rust we have the better option of "just say they can't do that" by default, with the easy derive opt-in for "yes, the structural behaviour is fine for my type".