| I'm (one of) the author of Tokio, hopefully I can clarify some points. > Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions. IMO, this is largely due to the current state of the docs (which are going to be rewritten as soon as some API changes land). The docs were written at a point where we were still trying to figure out how to present Tokio, and they ended up focusing on the wrong things. The Tokio docs currently focus on a very high level concept (`Service`) which is an RPC like abstraction similar to finagle. The problem is that, Tokio also includes a novel runtime model and future system and the docs don't spend any time explaining this. The next iteration of Tokio's docs is going to focus entirely at the "tokio-core" level, which is the reactor, runtime model, and TCP streams. tl;dr, I think the main reason people have trouble learning Tokio is because the current state of the docs are terrible. > Aren’t abstractions supposed to make things easier to learn? Tokio's goal is to provide as ergonomic abstractions as possible without adding runtime overhead. Tokio will never be as "easy" as high level runtimes simply because we don't accept the overhead that comes with them. The abstractions are also structured to help you avoid a lot of errors that tend to be introduced in asynchronous applications. For example, Tokio doesn't add any implicit buffering anywhere. A lot of other async libraries hide difficult details by adding unlimited buffering layers. |