-
tokio
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
The idea behind message-io is not to populate a current transport with a lot of options/profiles/modifications... this obfuscates the default way of working with it. Instead, if you want to build some behaviour on top of it, it is as easy as making an adapter! Following this pattern, you can split the way of using the library from the behaviour of the transport, keeping the things simple.
This is because I removed the word "asynchronous" from the readme to not generate noise with the concept of async/await (used in tokio for example). message-io is asynchronous in the sense that it handles non-blocking sockets, but does not make use of async/await. instead, it uses the event-driven pattern. This is because following with the idea of making the things simplest, adding async/await would introduce a new level of complexity/concepts to deal with.
I think that you are referring to something like laminar or turbulence do.
Message-io is a library that offers non-blocking network communication. You don't need to deal with async/await because it manages those asynchronous concepts inside. It could be seen as an upper layer. In fact, message-io uses mio, the non-blocking socket library from tokio.