bastion
smol
Our great sponsors
bastion | smol | |
---|---|---|
15 | 9 | |
2,759 | 3,414 | |
1.1% | 2.7% | |
0.0 | 6.8 | |
about 1 year ago | 7 days ago | |
Rust | Rust | |
Apache License 2.0 | 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.
bastion
- Write Elixir NIFs in Rust
- Bastion – Highly-Available Distributed Fault-Tolerant Runtime for Rust
-
lunatic v0.9 released - Bringing Erlang's supervisors to Rust
How is this better / different than https://github.com/bastion-rs/bastion ?
-
Introspection in Erlang/BEAM-inspired Async-Rust-Executors?
There are attempts to implement an Erlang/BEAM-inspired reactor/runtime/executor/ecosystem for Rust's Async, in particular Bastion. (There are also Lumen, Lunatic and Async-Backplane/Async-Supervisor.)
- What is the current state of actor systems in Rust?
-
Announcing "Zestors": A simple, fast and flexible actor-framework
I would be interested in an example showing how to build a robust runtime like bastion with fault tolerance.
-
Async feedback from 2 years of usage
But the issue you're referring to, building a fault-tolerant web server where you can have granular control over killing background jobs regardless if they're blocked on a syscall, totally requires using this kind of software architecture. See Bastion.
-
Can one code different kind of multithreading paradigms in Rust (BEAM, Node, Go)?
Bastion, a Rust async runtime inspired by the beam distribution and supervision model
-
Linus Torvalds on Rust support in kernel
I don't really know much about erlang, but I think this may be along the lines of what you are thinking of: https://github.com/bastion-rs/bastion
(I also don't really think the linux kernel people would be interested...)
-
Lunatic - An Erlang inspired runtime for all programming languages
This reminds me of bastion. Looks like it attempts to fulfill the same needs, though I guess Lunatic has native WASM support whereas bastion might require some tweaking to have it work? Haven't worked with bastion, so that part of harder time with WASM is just a wild speculation. On the other hand bastion looks much more mature. Probably /u/vertexclique could give a more informed opinion about the difference between the two ;) I really like what these projects are putting forward.
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...
What are some alternatives?
actix - Actor framework for Rust.
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
lunatic - Lunatic is an Erlang-inspired runtime for WebAssembly
async-std - Async version of the Rust standard library
tiny-tokio-actor - A simple tiny actor library on top of Tokio
reqwest - An easy and powerful Rust HTTP Client
rustig - A tool to detect code paths leading to Rust's panic handler
async-std-hyper - How to run Hyper on async-std
riker - Easily build efficient, highly concurrent and resilient applications. An Actor Framework for Rust.
ureq - A simple, safe HTTP client
async-backplane - Simple, Erlang-inspired fault-tolerance framework for Rust Futures.
rio - pure rust io_uring library, built on libc, thread & async friendly, misuse resistant