Threads cannot scale at all, because you're limited to the number of threads (which is usually quite small).
Async code can scale essentially infinitely, because it can multiplex thousands of Futures onto a single thread. And you can have millions of Futures multiplexed onto a dozen threads.
This makes async ideal for situations where your program needs to handle a lot of simultaneous I/O operations... such as a web server:
> So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still being able to write code like it’s a single thread.
thread_local! exists, and you can just call spawn_local on each thread. You can even call spawn_local multiple times on the same thread if you want.
You can have some parts of your programs be multi-threaded, and then other parts of your program can be single-threaded, and the single-threaded and multi-threaded parts can communicate with an async channel...
Rust gives you an exquisite amount of control over your programs, you are not "stuck" or "locked in", you have the flexibility to structure your code however you want, and do async however you want.
You just have to uphold the basic Rust guarantees (no data races, no memory corruption, no undefined behavior, etc.)
The abstractions in Rust are designed to always uphold those guarantees, so it's very easy to do.
Even the costs you are talking about are a one-time cost to read the documentation and learn the abstraction. And the long-term benefits of the abstraction are far greater than the one-time costs. That's why we create abstractions, because they are a net gain. If they were not a net gain, we would simply not create them.
I never said that ALL abstractions in Rust are zero-cost, though the vast majority of them are, and you actually have to explicitly go out of your way to use non-zero-cost abstractions.
I'm curious what things you consider to be half-baked about Rust async.
I've used Rust async extensively for years, and I consider it to be the cleanest and most well designed async system out of any language (and yes, I have used many languages besides Rust).
We're talking about the comparison between using an abstraction vs not using an abstraction.
When I said "doesn't have a runtime cost", I meant "the abstraction doesn't have a runtime cost compared to not using the abstraction".
If you want your computer to do anything useful, then you have to write code, and that code has a runtime cost.
That runtime cost is unavoidable, it is a simple necessity of the computer doing useful work, regardless of whether you use an abstraction or not.
Whenever you create or use an abstraction, you do a cost-benefit analysis in your head: "does this abstraction provide enough value to justify the EXTRA cost of the abstraction?"
But if there is no extra cost, then the abstraction is free, it is truly zero cost, because the code needed to be written no matter what, and the abstraction is the same speed as not using the abstraction. So there is no cost-benefit analysis, because the abstraction is always worth it.
The whole point of an abstraction is to remove complexity for the user.
So I assume you mean "implementation complexity" but that's irrelevant, because that cost only needs to be paid once, and then you put the abstraction into a crate, and then millions of people can benefit from that abstraction.
Yes, you can do that. You can use `block_on` to convert an async Future into a synchronous blocking call. So it is entirely possible to convert from the async world back into the sync world.
Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost.
That makes abstractions far more useful and powerful, since you never need to do a cost-benefit analysis in your head, abstractions are just always a good idea in Rust.
Rust Futures are essentially green threads, except much lighter-weight, much faster, and implemented in user space instead of being built-in to the language.
Basically Rust Futures is what Go wishes it could have. Rust made the right choice in waiting and spending the time to design async right.
I think there are a couple important details you are missing...
First, wasm-pack is not Ashley's personal project, it is an official Rust Wasm project. That means it is owned by the Rust Wasm team, and it is maintained by the Rust Wasm team. It is an official part of Rust, similar to how cargo and rustdoc are an official part of Rust. wasm-pack was never intended to be maintained only by Ashley.
Multiple Rust Wasm Core team members (including myself) politely asked Ashley multiple times to transfer publishing rights to the Rust Wasm Core team (which she was supposed to have done months ago), but she refused.
Multiple people had politely offered to take over maintenance of wasm-pack (when it was clear that Ashley was unwilling to do so), but once again she refused. She knew how important wasm-pack is to Rust Wasm, but she did not want to give up control and power, even though it wasn't even supposed to be her package in the first place.
Second, forking is not as simple or as easy as you claim... forking is something that has a very high cost, so it should be done as a last resort. wasm-pack is an official Rust package (and it is vital to Rust Wasm), and so forking it would have a lot of costs:
* A new crate would have to be created (what should it be called? wasm-pack2?)
* The GitHub repo would have to be changed or transferred.
* Multiple different documentation websites (including the official Rust website) would need to be updated.
* A newsletter would need to be sent out informing everybody of the change.
* All existing projects would need to switch to the new package.
* The old package would still exist, which would be very confusing for people, especially because many tutorials and blogs would still be referring to the old wasm-pack!
* Ashley herself would throw a huge tantrum over it, because she would view it as taking control away from herself. And because she is a Rust Core team member, her tantrum would have power behind it.
Forking is absolutely NOT an appropriate solution in this case. Ashley's behavior was simply wrong, unacceptable, and reflects very poorly on the Rust team (which she is a part of).
As for Ashley's personal character... before she worked for Rust, she worked for npm. While she was working there, she tried to falsely accuse Rod Vagg because she wanted to kick him out of npm. Thankfully she failed, and after she failed she quit npm:
While she was working for npm, she violated npm's Code of Conduct numerous times, saying incredibly horrible sexist and racist things such as "kill all men", and actively trying to prevent white men from speaking at tech conferences:
No, she was not joking, and even if it was "just a joke" it is unacceptable. If a man said "kill all women" even as a joke he would be immediately fired and blacklisted from all companies.
Despite all of this, she was still hired onto the Rust Core team, because she is in a romantic relationship with Steve Klabnik (nepotism). Interestingly, Steve Klabnik is also the same person who is smearing Amazon because Amazon denied a job to Ashley.
The Rust Core team was aware of Ashley's past behavior, yet they hired her anyways. And even though numerous people spoke out about this, they were silenced and censored by the Rust team:
She also made numerous lies in those two threads (such as claiming that the Rust Wasm Core team is "random people without organization", the Rust Wasm Core team is hand-picked, they are the official leaders of Rust Wasm).
She acted incredibly disrespectful toward the Rust Wasm team (who worked very hard to make Rust work on Wasm), even though she had contributed basically nothing.
There is a dark side to Rust, which everybody is afraid to talk about. Anybody who tries to discuss things is censored by the Rust Core team. That's why I stopped contributing to Rust and I will never go back.
Async code can scale essentially infinitely, because it can multiplex thousands of Futures onto a single thread. And you can have millions of Futures multiplexed onto a dozen threads.
This makes async ideal for situations where your program needs to handle a lot of simultaneous I/O operations... such as a web server:
http://aturon.github.io/blog/2016/08/11/futures/
Async wasn't invented for the fun of it, it was invented to solve practical real world problems.