To be honest, reading mainly blog posts, RFCs and summarisation comments, it did look like a thoughtful and organised process. However, there has been a constant problem of tiresome work and "intellectual and emotional labour" of reading thousands pieces of feedback, some of which are emotionally charged, and many of which are duplicates or re-statements of similar ideas, and many of which have misunderstanding or mis-valuations of other ideas. I've heard that collecting and editing this huge amount of unstructured feedback into comprehensive and balanced summaries has been a huge drain of mental energy for the participants.
I wasn't involved at all in the discussion, but having dove deep into async over the past few months since async/await was stabilized, I definitely am happy with the result of that process. Writing code with postfix `.await` feels very natural to me and it fits it much better with the surrounding code I write than a prefix version would. I can sympathize that participating in that process might not have been fun, but I really hope that the results of future discussions make me as happy as this one has.
> Writing code with postfix `.await` feels very natural to me and it fits it much better with the surrounding code I write than a prefix version would.
That’s your subjective point of view, not everyone agrees with it. Part of the problem is that Rust team failed to find a solution good enough for the most people and failed to communicate this decision. In particular the switch to .await syntax happened just couple weeks before it was finally stabilized.
And await is not the only controversial decision made by the Rust team.
Even if 10% of people unhappy that’s too much, because the next controversial feature will cause 10% more of unhappy people and so on.
I might be wrong but for C++ for example every C++ fan seems to happy about every new release (at least happy with new features, not lack of desired new features).
Same for Java, IIRC the only controversial decision they made was the introduction of modules.
Python 3 was a mistake, but generally Python users are happy with Python changes.
10% is not impossible. Even if this decision is ”right”, communication could be better: more options to play with different syntaxes, more time to get used to new syntax before stabilizing are just two possible ways to deal with the angry mob.
> I might be wrong but for C++ for example every C++ fan seems to happy about every new release (at least happy with new features, not lack of desired new features).
I believe you are mistaken. C++ community has a lot of diverse opinions about its features. As an old saying goes, it is possible to use only the good subset of C++ features, the problem is every shop has its own subset. Even about something as basic as exceptions there is no consensus. Similarly, not everybody is happy about the "modern C++" movement. I guess these people are just confident that thanks to serious commitment to backwards compatibility they will be able to continue writing code in their old grumpy ways so there is no need to loudly express their dissatisfaction.
Rust community is much less fractured (in part because it is smaller and younger) and there is a sense that decisions made today will determine how everybody will write Rust code tomorrow. Combine that with efforts to encourage an inclusive discussion and you get a lot of disagreement visible in discussions, especially concerning aspects that are prone to bikeshedding.
> I might be wrong but for C++ for example every C++ fan seems to happy about every new release (at least happy with new features, not lack of desired new features).
Coroutines were quite co_ntentious.
Maybe the difference is that very few C++ developers live on the bleeding edge. I don't use anything unless it's available from the default packages on an LTS release. So, I won't be using C++17 until I update to Ubuntu 20.04 later this year. And compared to the older developers in my lab, I'm an early adopter.
By the time new features reach the average C++ programmer, they're just how things are. The pain and the fighting of the standardization process is just distant memory that happened to somebody else.
> I might be wrong but for C++ for example every C++ fan seems to happy about every new release (at least happy with new features, not lack of desired new features).
If anything if 10% of C++ users are happy with the new features in a release it's a great success. I see a lot of complaining about the committee, its decisions, and its decision-making process.
C++11 introduced std::async and std::future. Pretty much everybody uses something else nowadays (std::async is a deprecated footgun, std::future should have been a Concept instead of a concrete type, etc.) and some parts of this design impact new language features like C++ coroutines, which 50% of the people say are good enough, and the other 50% say "they are not zero cost and as fast as Rust's".
Major new features of this size in C++11 are lambdas, variadic templates, auto, and move references. C++14 adds generic lambdas. C++17 adds constexpr if and structured bindings. C++20 adds concepts, coroutines, and modules.
The syntax had been proposed long before then; I (along with others) had been advocating for it the prior year. The May 6 blog post was merely the point at which the blog post author relented to the rest of the lang team to bring it up for a vote.
As for your second sentence, RFCs are almost always accepted before they are implemented. There is an entirely separate round of review and approval before an accepted RFC can become a stable feature of the language.
