Hacker News new | past | comments | ask | show | jobs | submit login

Can you help understand why somebody wouldn't use Tokio/why it didn't "win"?



Tokio isn't the fastest conceivable runtime. Tokio isn't the smallest conceivable runtime. Tokio isn't the simpilist conceivable runtime. Tokio does not port to all conceivable environments. Tokio isn't the async-std runtime.

And so, for some or all of these reasons, right or wrong, various Rust libraries wed themselves to runtimes other than Tokio.

You can thunk around these things, but it's miserable, yielding subtle, inscrutable code that you will not understand in six months when you have to maintain it. And the real fun begins when you need to handle Err, and all the abstraction leaks around Send and threads ruin your day; more thunking, Boxing errors (omfg) and even subtler and more inscrutable code.


Is this to say async-std is faster + smaller + simpler + more portable than Tokio?


I think what they were trying to say is that Tokio ended up being a general purpose async runtime so naturally it can't be the most optimal solution for every case. But because various libraries kind of force you into Tokio, it's very hard to use a runtime that's optimal for your specific problem. You'd have to give up on a lot of convenient libraries out there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: