Think Twice Before Using Async Rust | Prime Reacts

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))

[cocacodes]

To those who are interested in isolating async rust in a application you can do so by creating a creating a async runtime in a different thread from main. Then you can share data between the async runtime and your sync rust using ideally a channel or some global data.

In Tokio the `#[tokio::main]` macro is just a wrapper for the `tokio::runtime::Builder` which when built calls `Runtime::block_on`. You can easily do all of this inside a thread instead of main and have your own isolated async runtime.

[jsham]

The development of async-std slowed down because the rust team is working on providing that functionality as part of std::async. So, hopefully at some point in the future, we will see (most of) the ecosystem defragmentation go away - they will all use std::async without depending on a specific runtime.
The compiler team is working hard on implementing async traits as a language feature, which will allow the development of std::async to the standard of the rust std library.

[foxcirc]

I actually used to dislike async rust a lot. (Tokio is really overkill for most use cases imo, it also adds like 300 dependencies) But using async-executor etc. directly (basically the crates that smol is built ontop of) and futures-lite was a really nice experience (even tho some features are missing). I managed to get everything I need with only about 20 dependencies. This can even be used as a replacement for coroutines for easy parrallelism and now I actually really like async rust. I think the whole smol stack is really great.

[theohallenius]

Not including async as default feature of Rust's language was the biggest mistake, now it's a complete mess

[avalagum]

There's the Async Rust book by Maxwell Flitton and Caroline Morton which is scheduled to be published in Dec 2024. That book uses Tokio. So I guess that Tokio will be the de-facto async thingy in Rust.

[Rose-eche]

I haven't watched the video completely, here are my initial thoughts.
The article being reviewed seems kinda whiney, there's many options to choose from but the most common is tokio. Unless if you have specific requirements for your asunc runtime you just use that. The alternative is having a single async runtime for the language which is very limiting. Library implementors choosing to support multiple runtimes is an unfortunate result of this choice. The complaints about async rust being difficult to write seem silly to me, asynchronous code is extremely complicated and error prone to write without rust's compile-time checks. It forces you to consider the real complexity of what asynchronous code actually involves and do it right. It's also silly to complain that it doesn't work in bare metal environments, because such environments cannot support OS threads, locks or other basic things that you need to correctly write asynchronous code. Asynchronous code aslo has massive overhead that you do not want in bare metal applications. It seems kind of complaining that the writer of the article can't have their cake and eat it too

[didiervvs]

I so dislike when developers (even experienced ones) think they can just "ejaculate" (as you coin it) code. All those I've seen that think they can just fail miserably as soon as the task at hand is a little tricky. I always recommend mental model first, or pen and paper, then code.

[RicardoSansores]

This is how software evolve. Tokio is the defacto standard just like Spring was and is the defacto standard even when JEE was created. The best library will prevail. That's it.

[spicynoodle]

10ms seems long but that's probably for running a script from the shell. In a server configuration, php-fpm caches the bytecode of your program in RAM and on top of that you can enable JIT. I don't have a bench but it should be way faster than 10ms because locally I usually see 10ms time for a response with HTML templating and what not.

[lucaslopes]

You can tell Prime is a very trustworthy and reliable person by how transparent he is.

[flanger]

"This one of the problems about Rust in general [...] they want you to know everything before you program anything" YUP. And what I've been doing instead is just ignoring this and starting to code shit. Like, I can simply decide that I'm going to write stuff and if I don't know enough yet, I'll certainly reach that bridge and decide whether I'm going to jump off it or not.

[kuhluhOG]

2:00 That's actually why I like the sender and receiver proposal for C++.

[MrHirenP]

My understanding of Rust’s async model is that the language should provide async variants of I/O methods that return Futures. It is then up to the developer to decide how to put the Futures together to build up a runtime. How did it happen that making an async web request requires the Tokio runtime? I feel like somewhere there was a breakdown in communication. I’m just getting acquainted with Rust, so pardon my naive question.

[marvinmokua]

@prime Have you done a video on helix yet?

[uowemegrand]

Is Box dyn error bad? I thought type erasure for error propagation is good? Especially considering how you also have the option of downcasting it back to the concrete error type after. Genuinely curious.

[shavais]

Channels use locks? I guess while waiting to recv, you're waiting on something that might as well be a lock if it isn't, but what's the alternative? Spin? If there's already something in the queue you don't wait on a lock, right? Isn't the whole idea of an mpsc queue that it's lock free?

Can you elaborate on what the problems are with Box<dyn Error>?

[ChronosWS]

at 16:20 you talk about the reflexive "just _ ignore the error". This is actually one of the bad habits newbies need to learn to suppress. The whole point of the compiler telling you you didn't handle something is that you are almost certainly making a mistake, and you should take it seriously. Setting aside whether async programming and futures are bad - arguable - the habit of ignoring errors absolutely will destroy you.

[duke]

Ya... When I use async rust I also get a little pissed about it. Coming from Go, it just seems like there was such an easier way than function colouring and having to have 2 functions for everything that can block. 1 that blocks and 1 that returns a future. I loved async in JS then I tried Go and saw how much nicer it could be, shame Rust when down the async path instead of goroutine path. Or even zig. Haven't done any async zig (on account of them removing it) but from the documentation zig also looks to be colourless, having to opt into async at call time by prepending the call with `async`

[spookyconnolly]

reminded of the Boehm paper about pthreads and not implementing threads as a library again

[Silverdagger]

Man yelling on top oh his lungs almost every other video ~4 months ago questions whether he is a Tokio andy?