Beul - it executes futures | by Bert Peters
"Beul is a minimalistic futures executor. No dependencies, no unsafe #Rust. It simply executes futures."
It can't get any simpler than that. ¯\_(ツ)_/¯
@noboilerplate THIS!
I think a lot of people inadvertently assume async #RustLang is so different from sync Rust, because the way it is - when in fact it's because of the (most popular) async runtime they're using.
We should look way more into alternative #async runtimes to #Tokio, e.g. smol:
https://floss.social/@janriemer/111669258656959538
#Smol allows you to use non-'static Futures by using a local executor:
https://floss.social/@janriemer/111669668856899636
It looks a lot more like "normal" #Rust.
Yay! @[email protected] is working on `smol` integration with #axum! :awesome: https://github.com/notgull/smol-axum The smol #async runtime: https://github.com/smol-rs/smol #Tokio is not the end-all-be-all runtime. You should keep looking at alternatives and what unique features they can offer. ✨ Don't be blinded by "if it is the most popular, it must be the best" fallacy. #Rust #RustLang #RustAsync #AsyncRust
Beul - it executes futures | by Bert Peters
"Beul is a minimalistic futures executor. No dependencies, no unsafe #Rust. It simply executes futures."
It can't get any simpler than that. ¯\_(ツ)_/¯
Clippy's lints for dealing with #async in #Rust:
https://rust-lang.github.io/rust-clippy/master/#/async
(Note, that this is just a search for the term "async" in the Clippy docs - there is no special "category" involved here).
Asynchronous streams in #Rust (part 1) - Futures, buffering and mysterious compilation error messages - by Guillaume Endignoux (@gendx) (April 2021)
https://gendignoux.com/blog/2021/04/01/rust-async-streams-futures-part1.html
Asynchronous streams in Rust (part 2) - Cancelling expired requests
https://gendignoux.com/blog/2021/04/08/rust-async-streams-futures-part2.html
Yay! @notgull is working on `smol` integration with #axum!
https://github.com/notgull/smol-axum
The smol #async runtime:
https://github.com/smol-rs/smol
#Tokio is not the end-all-be-all runtime. You should keep looking at alternatives and what unique features they can offer. ✨
Don't be blinded by "if it is the most popular, it must be the best" fallacy.
This thing will (probably) blow up 🚀
mfio - Framework for #Async I/O Systems:
https://github.com/memflow/mfio
"mfio is a one-stop shop for custom async I/O systems. It allows you to go wild, beyond typical OS APIs.[...]"
- Async
- Automatic batching (vectoring)
- Fragmentation
- Partial success
- Lack of color (full sync support)
- I/O directly to the stack
- Using without standard library
@matze Yes, that's true.
However, writing the desugared version in the trait is still compatible with using async fn in the _trait impl_, so the "burden" is more on lib maintainers.
Also this problem only applies when the Self type is generic.
And `Send` is only required, if one decides to use a multithreaded rt.
I highly recommend the following article by @notgull about smol:
Why you might actually want async in your project
*makes some happy screaming noise*
#Rust will end this year with a long awaited feature that will define it's future:
We will get "async fn and return-position impl Trait in trait" (#AFIT & #RPITIT).
It will be stabilized in the next #RustLang version 1.75, which will be released on 28 December, 2023.
https://releases.rs/docs/1.75.0/
PR:
https://github.com/rust-lang/rust/pull/115822
Thank you Rust #community for all of your hard work! ❤️
@notgull This is such a good blog post. I've learned a lot!
Thank you for sharing. ❤️
"The best part is that the allocation, the Vec<smol::Task<()>>, isn’t even necessary. It could be one-time allocation that is just extended to hold the tasks."
Wow, this is mind-blowing to me - I haven't even considered this before! 🤯
Memory-reuse FTW!
For more visibility => #Rust #RustLang #Async #RustAsync #Smol