@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.

#RustAsync #AsyncRust #Concurrency

Jan :rust: :ferris: (@[email protected])

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

FLOSS.social

Beul - it executes futures | by Bert Peters

https://lib.rs/crates/beul

"Beul is a minimalistic futures executor. No dependencies, no unsafe #Rust. It simply executes futures."

It can't get any simpler than that. ¯\_(ツ)_/¯

#RustLang #RustAsync #Async #AsyncRust

beul

It executes futures

Lib.rs

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).

#RustLang #RustAsync #Clippy

Clippy Lints

A collection of lints to catch common mistakes and improve your Rust code.

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

#Rust #RustLang #AsyncRust #RustAsync #Async

Asynchronous streams in Rust (part 1) - Futures, buffering and mysterious compilation error messages | Blog | Guillaume Endignoux

If you are already reading my blog, you may have noticed that I see a lot of potential in the Rust programming language.The safety and efficiency properties ...

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.

#Rust #RustLang #RustAsync #AsyncRust

GitHub - notgull/smol-axum: `smol` integrations with `axum`

`smol` integrations with `axum`. Contribute to notgull/smol-axum development by creating an account on GitHub.

GitHub

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

#Rust #RustLang #RustAsync #AsyncRust #Memflow #IO

GitHub - memflow/mfio: memflow I/O primitives

memflow I/O primitives. Contribute to memflow/mfio development by creating an account on GitHub.

GitHub

@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

https://notgull.net/why-you-want-async/

#Rust #RustLang #RustAsync #AsyncRust

Why you might actually want async in your project

There is a common sentiment I’ve seen over and over in the Rust community that I think is ignorant at best and harmful at worst.

notgull

*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! ❤️

#RustAsync #AsyncRust

@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

Today I've been working with async #rustlang for a personal project. Anyone knows where to find updated docmentation about it? 😭
#rust #rustasync #async