I’m trying to learn Tokio and finding it too complicated. The problems for me are:
- The sheer number of types involved.
- Choice of names for the types is such that they don’t indicate the intent clearly.
- Also at a coarser level, many things seem non-intuitive. For example, why is a ServerProto, which is meant to represent a protocol, creating a transport? There are many such design choices which are non-intuitive.
While I’m really impressed by the separation concerns Tokio has achieved, trying to put all its pieces simultaneously into a big picture is proving very challenging for me.
This of course is a very subjective opinion of mine. Just wanted to know from you all what your experience has been so far.
Just to expand a bit, the following are the abstraction that I found to be well designed, simple and easy to understand:
- Io/Framed <— this one just a tiny bit less intuitive than the first two (not the concept but the implementation), but still good enough
Abstractions I found difficult to understand and less intuitive:
- ServerProto/ClientProto <-- I’m not sure why they are called protocols. They are not protocols at all. They just converters that change an IO object into something the Service can consume. Should’ve been called 'Binders` maybe.
- reactor::Core <— I know this is built atop non-blocking io which in itself can a slightly difficult concept to get. However I found the mio library pretty simple and easy to understand. Not sure why Core couldn’t be similarly intuitive.
- PollEvented <— Again the same observations apply here as the preceding point, but I still feel this could have been designed in a more clear way.
In comparison, Finagle, by whom Tokio is inspired, is based on the concepts of a Service and a Filters which is a model that’s far simpler and natural.
Once again, all subjective opinions. Would love to know what others think