I'm (one of) the author of Tokio, hopefully I can clarify some points.<p>> Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions.<p>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).<p>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.<p>The Tokio docs currently focus on a very high level concept (`Service`) which is an RPC like abstraction similar to finagle.<p>The problem is that, Tokio also includes a novel runtime model and future system and the docs don't spend any time explaining this.<p>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.<p>tl;dr, I think the main reason people have trouble learning Tokio is because the current state of the docs are terrible.<p>> Aren’t abstractions supposed to make things easier to learn?<p>Tokio's goal is to provide as ergonomic abstractions as possible <i></i>without adding runtime overhead<i></i>. Tokio will never be as "easy" as high level runtimes simply because we don't accept the overhead that comes with them.<p>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.