blessed-rs
monoio
blessed-rs | monoio | |
---|---|---|
6 | 23 | |
1,174 | 3,616 | |
- | 3.8% | |
6.7 | 8.0 | |
13 days ago | 8 days ago | |
HTML | Rust | |
- | Apache License 2.0 |
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.
blessed-rs
-
Crate List - Blessed.rs
I opened a PR to correct this.
-
Blessed.rs – An unofficial guide to the Rust ecosystem
This is my project (although I didn't submit this to HN), AMA
I consider quite incomplete at this point (but hopefully already useful). There are several categories of crate that just aren't covered yet (suggestions very welcome, either here or on the github repo https://github.com/nicoburns/blessed-rs).
I'd also like to add more hand curated content such as:
- Installation and developer environment setup
-
What crates are considered as de-facto standard?
No, it's hand curated (see https://github.com/nicoburns/blessed-rs for source). There is a separate project https://lib.rs that takes a more automated approach (you can browse the most downloaded crates by count).
-
Enable VSCode lifetimes elisions hints to learn about lifetimes
This sounds like the sort of thing I created https://blessed.rs to host (source: https://github.com/nicoburns/blessed-rs). I never really launched it, so it's a bit incomplete atm. But the idea is that it's a guide to all the stuff that can't be in the official docs (because that would be favouritism), but that every rust developer ought to know.
-
I want to improve project management practices for the Rust Lang team!
I've been quietly working on something like this over at https://blessed.rs (source: https://github.com/nicoburns/blessed-rs) At the moment it's just a curated list of crates (and still a fairly short one at that), but the vision is very much to be a go-to knowledge base for Rust, a community managed counterpart to the official website. I've been putting off an announcement until it's more ready, but perhaps it's better to get it out there.
-
Q about Rust Microservices
My dockerfile: https://github.com/nicoburns/blessed-rs/blob/main/Dockerfile.build
monoio
- How to Visualize and Analyze Data in Open Source Communities
-
Core to Core Latency Data on Large Systems
There is also another thread-per-core implementation by ByteDance (TikTok) for Rust called Monoio with benchmarks[0] comparing it to Tokio and Glommio.
[0] https://github.com/bytedance/monoio/blob/master/docs/en/benc...
-
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.
-
Why does Actix-web's handler not require Send?
I assume Tokio itself, see e.g monoio or glommio, but also Seastar for C++.
-
Introducing `rudis`: A Sharded, Concurrent Mini Redis with Web Interface in Rust
I think monoio is also thread-per-core but also iouring https://github.com/bytedance/monoio. I don't know how you would shard certain keys into different threads, but if you can do that deterministically then there could be a significant speed up.
-
How does async Rust work
I believe this is also "thread-per-core".
-
Oxy is Cloudflare's Rust-based next generation proxy framework
Bytedance has their in-house monoio <https://github.com/bytedance/monoio> (supports io-uring) but it requires rust nightly.
-
Is async runtime (Tokio) overhead significant for a "real-time" video stream server?
There's another thread-per-core runtime called https://github.com/bytedance/monoio
-
Blessed.rs – An unofficial guide to the Rust ecosystem
It's worth mentioning: Under "Async Executors", for "io_uring" there is only "Glommio"
I recently found out that ByteDance has a competitor library which supposedly has better performance:
https://github.com/bytedance/monoio
https://github.com/DataDog/glommio/issues/554
-
hyper v1.0.0 Release Candidate 1
I see that, I also tried with monoio, but the developer of that runtime mentioned that https://github.com/bytedance/monoio/blob/master/examples/hyper_server.rs might have soundness issues
What are some alternatives?
argparse-rosetta-rs - Comparing argparse APIs
glommio - Glommio is a thread-per-core crate that makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans.
serde-regex - A serde wrapper that allows to (de)serialize regular expressions
tokio-uring - An io_uring backed runtime for Rust
delimited
config-rs - ⚙️ Layered configuration system for Rust applications (with strong support for 12-factor applications).
wg-async - Working group dedicated to improving the foundations of Async I/O in Rust
cap-std - Capability-oriented version of the Rust standard library
actix-net - A collection of lower-level libraries for composable network services.
Tide - Fast and friendly HTTP server framework for async Rust
MIO - Metal I/O library for Rust.
windows-rs - Rust for Windows