I'm just an outsider looking in, with no skin in the game. Feel free to ignore me. 8)
Pease allow me a chance to clarify the (very off-topic) point that I was trying to make, I don't want to be seen as advocating for more rudeness, because obviously that's not constructive...
My entirely unscientific observation over decades is that successful languages seem to be usually designed by surprisingly few key people, providing "a clear design direction", at least initially. E.g.:
- C - Dennis Ritchie
- C++ - Bjarne Stroustrup
- Python - Guido van Rossum
- Perl - Larry Wall
- Java - James Gosling
- Ruby - Yukihiro Matsumoto
- JavaScript - Brendan Eich
I agree with you that Linus-style leadership is probably not the best example to use, because he can definitely rub people the wrong way. So instead, consider the list above, because it's more apt to Rust anyway. Are any of those people rude? Brash? I don't think so, or at least not infamously so, like Linus. Still, I would argue that their clear leadership was required for the success of their languages.
Notably, most of those languages have changed over time, being taken over by cooperating committees or communities with no clear leadership. In particular, C and C++ have stagnated and wandered around aimlessly for over a decade because of the incompatible requirements of the various vendors all having their say.
It's entirely possible that Rust can develop to be a successful, widely used language that isn't relegated to some specialised niche. I'd love it, if this happened! I'm also watching the community-driven process with absolute fascination. Maybe it can work! It's certainly educational to watch it all unfold in real time. To my knowledge, no mainstream language has ever started out community-driven and succeeded. Maybe Rust can pave the way...
A side-note on tokio improving: coincidentally, this was just posted today:
In particular, this bit is impressive:
For a long time, many users have asked for us to remove the Error type from Future, because they did had a non-IO use case in which the Error type was inappropriate. We’ve come around to agreeing with them; having the Error type would require that async functions always return a Result, and would not enable non-IO use cases for asynchronicity (such as lazily & concurrently evaluated pure computation).
So in this case at least the community process seems to have worked! The "pollution" of the Future trait with std::io::Error was one of my main issues with its design, and it seems that similar feedback by others with a similar opinion has had positive impact. 8)
However, note this warning from a post about the announcement: Be careful with this. I'm not saying you should not do it, but consider you'll h... | Hacker News
Languages like Python, Perl and JavaScript have been taken over by their open, anyone-can-contribute module systems and usually this has resulted in an absolute mess. I'm just a bit concerned that Rust is headed down the same path, and that this is hard to see during the honeymoon phase when it hasn't yet scaled up to the point that it has 8 different incompatible async I/O libraries like Python...