I would gladly switch to a Rust fork without async. Even though this article is not about async per se, it’s clear that async makes most of the described problems worse.
Author here. I think async is a great feature to have - but I can't help but wonder if you're right. It might just be case of timing, but it seemed like once async was in the works, work on the rest of the language ceased. For awhile there all energy was poured into bikeshedding over how async would work. And I don't know if anyone is super happy with the result. Pin is a mess. Async functions still return anonymous objects - which cause all sorts of problems. And there still aren't coroutines in the language, even though async functions are implemented internally using coroutines anyway.
If we could go back in time and have the rust project decide to never implement async, I wonder what rust would look like today. There's a good chance the language & compiler would be much nicer as a result.
But it probably is a prerequisite for any project achieving its mission on a large scale. I'd rather have a programming language that makes a big positive impact in the security, reliability, and efficiency of software that lots of people use, than one that's aesthetically pleasing but not widely used.
C and C++ were never sponsored by large companies, and they did just fine. Zig is the same, today. (It has some small sponsors, but nothing like the corporate support of rust.)
>C and C++ were never sponsored by large companies,
I don't know what you had in mind for "sponsored" but others would disagree and say both C and C++ were "sponsored by AT&T Bell Labs" because the people who created them (Dennis Ritchie, Bjarne Stroustrup) were employees of AT&T. Analogous to Rob Pike, et al. of Go Language being employed/sponsored at Google.
I think Rust's `async` has been a great success for commercial "sponsors" of Rust, because it increased the complexity of the language so much that it's hardly possible anymore to contribute to it without being full-time employed to do so.
The decision for `async` handed a lot of power to Amazon et al.
Isn't that trivial? Just use Rust but reject any occurrence of `async` or `await` in your code or dependencies. Rust doesn't even force the use of async code for certain features in its standard library.
The problem is the ecosystem split and the decades of man hours of churn caused in libraries and user code – that's time and effort that could have been spent on making those dependencies better.
This applies to both suggestions ("fork" and "don't use it").
And use which first class libs? IO related libs are almost all based on Tokio. I mean I'm happy that at least there's some consent regarding the runtime. But you can't undo the decisions for going async (instead of green threads) that easily.
