I and many others would disagree that they made the decision "at the expense of the long-term Rust health". You aren't arguing in good faith if you put words in their mouth. There is no data to suggest the long-term health of rust is at stake because of the years long path they took in stabilizing async today. There are merits to both models but nothing is as clear-cut as you make it to be - completion-based futures are not definitively better than poll-based and would have a lot of trade-offs. To phrase this as "Completion based is totally better and the only reason it wasn't done was because it would take too long and Rust needed popularity soon" is ridiculous
I do not put words in their mouth or have you missed the "in my opinion" part?
The issues with Pin, problems around noalias, inability to design a proper async Drop solution, not a great compatibility with io-uring and IOCP. In my eyes they are indicators that Rust health in the async field has suffered.
>Completion based is totally better and the only reason it wasn't done was because it would take too long and Rust needed popularity soon
I find your statements so strange. I honestly don't care about noalias, and very few people really should. Same with 'async drop'. Same with io-uring, which seems to be totally fine in Rust so far.
Despite your repeated statements that async has harmed Rust, I don't have any problem whatsoever day to day writing 10s of thousands of lines of async code with regards to what you've brought up.
Yes, it's a real possibility. But the problem is that the other route was not properly explored, so we can not compare advantages and disadvantages. Instead Rust went all-in on a bet which was made 3 years ago.
