smol
rio
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
smol
-
The State of Async Rust
My understanding is you always need a runtime, somethings needs to drive the async flow. But there are others on the market, just not without the.. market domination... of tokio.
https://github.com/smol-rs/smol looks promising simply for being minimal
https://github.com/bytedance/monoio looks potentially easier to work with than tokio
https://github.com/DataDog/glommio is built around linux io_uring and seems somewhat promising for performance reasons.
I haven't played with any of these yet, because Tokio is unfortunately the path of least resistance. And a bit viral in how it's infected tings.
- Smol: A small and fast async runtime for Rust
-
Tokio for FFI app?
There is also https://github.com/smol-rs/smol which has components which you can compose into your own executor if you still need async IO but your usage patterns don't fit into the general purpose ones that Tokio provides.
-
Tokio application structure, critical code flow.
If you need precise control over scheduling, consider building something on top of https://github.com/smol-rs/smol
- Async Rust: What is a runtime? Here is how tokio works under the hood
-
18 factors powering the Rust revolution, Part 2 of 3
Tokio is a "take what you need" framework, whilst Async-std started as an "everything the box" solution. Today both have a lot of crossover with micro async runtimes like smol becoming the foundation one of framework and optionally usable in the other. The ability to rip out a small dependent sub-crate (dependent package) like smol and use it independently with ease never get's boring, by the way. It's great way to include a test runtime in an async library without forcing the inclusion of a giant async framework.
-
[Question] Is Tokio a poor fit for non-network related concurrent applications?
Helix uses tokio. smol might be a good alternative however.
-
Async feedback from 2 years of usage
No, still active on GitHub. What gave you that idea? https://github.com/smol-rs/smol
-
Tokio, the async runtime for Rust, hits 1.0
Found the issue in Google cache. I'm not sure it's really fair of me to post this link here, but equally I think it's better to give the actual text rather than leave it vague.
https://webcache.googleusercontent.com/search?q=cache:PRjMyv...
rio
-
Production grade databases in Rust
Also, not to be too bad about a reputation fallacy, but I found the author to be flippant and disrespectful when good-faith unsoundness was pointed out in his crates: https://github.com/spacejam/rio/issues/30
-
Linear Types One-Pager
In my previous post on linear types I spent quite a bit of time motivating linear types. For example the ergonomic rio io_uring library could be made sound if it could guarantee destructors are run. Or performing FFI with async C++ could be made more efficient if it could rely directly on destructors rather than having to involve an intermediate runtime for each call.
-
The Stigma Around Unsafe
It's like cargo should have a way to mark a dependency as unsafe. That way, you could have a safe mmap crate as an unsafe dependency. Or something like rio which is deliberately unsound (but is fine if you abide by its rules through the entirety of the program)
-
Anyone using io_uring?
for completeness there is also rio, but:
-
Comparing the Rust uring libraries (tokio-uring, glommio, rio, ringbahn)
rio still has known soundness issues– its Completion futures block the thread when dropped (!!!), and can allow for use-after-free bugs if leaked. See https://github.com/spacejam/rio/issues/30 for details.
-
kbio - Another Async IO Framework based on io_uring
Here are some posts about the design. https://without.boats/blog/io-uring/ https://github.com/spacejam/rio/issues/30 https://github.com/axboe/liburing/issues/109
-
Tokio, the async runtime for Rust, hits 1.0
The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT.
I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's.
I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely!
[1]: https://github.com/spacejam/sled
[2]: https://github.com/spacejam/rio
What are some alternatives?
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
io_uring-echo-server - io_uring echo server
async-std - Async version of the Rust standard library
KuiBaDB - Another OLAP database
bastion - Highly-available Distributed Fault-tolerant Runtime
cachegrand - cachegrand - a modern data ingestion, processing and serving platform built for today's hardware
reqwest - An easy and powerful Rust HTTP Client
fio - Flexible I/O Tester
async-std-hyper - How to run Hyper on async-std
kbio - Another Async IO Framework based on io_uring
ureq - A simple, safe HTTP client