Intro to Rust Async Function Execution With Smol 🦀 Rust Programming Tutorial for Developers

[@TrevorSullivan]

Check out some of these awesome components to upgrade your digital life! Thanks for helping support this channel! 🖥 AMD Ryzen 9 7900x 12-core CPU amzn.to/3EKdkSY 🖥 ASUS TUF Gaming B650-PLUS WiFi Socket AM5 (LGA 1718) Ryzen 7000 ATX Gaming Motherboard amzn.to/460IGAE 🖥 Corsair Vengeance 64GB (2x32GB) DDR5 memory amzn.to/3EMZhw0 🖥 Gigabyte GeForce RTX 4070 12GB Windforce amzn.to/453pIbr 🖥 Samsung 970 EVO Plus 1TB NVMe SSD amzn.to/3PNke0f 🖥 Thermaltake Smart 700W ATX PSU amzn.to/3rkXuuT Storage for cameras & embedded devices 💽 TEAMGROUP A2 Pro Plus Card 512GB Micro SDXC amzn.to/3PLd77l The drone I use ➡ DJI Mini 3 Pro 4k60 Drone amzn.to/3PLd77l My studio video camera ➡ Panasonic Lumix G85 4k amzn.to/3sXoDV7

[@jasonbraithwaite9204]

Another great Rust video by you Trevor. You always explain things very well and very clearly 👍

[@symshark]

Thank you! I've been waiting for this one.

[@TrevorSullivan]

Thanks! I will have more coming on the async topic. 🙂 Rust on! 🦀

[@shailendrajadhav8603]

Could you consider making a video to include async and thread spawning? This was a good introduction to async. Thanks for putting in the effort to make a visual presentation.

[@prashlovessamosa]

Thanks for everything 🙏. This is playlist more than enough for me Very grateful to you

[@alijoumma]

thank you for this video and other videos in this playlist, they are very useful and insightful, in the intro, I might misunderstood, but it sounded like you are saying async can't make things faster if you have 1 CPU, but that's only true for CPU bounded workloads (think intensive math calculations) but for IO bound operations (most calls external to the system like http call, db call) it actually makes things faster, because your 1 CPU doesn't have to wait at 0% utilization for the external resource to send a response, it can do other stuff until the external resource (db, website etc) sends data, which makes things faster with async with IO bound loads

[@TrevorSullivan]

Yes you're absolutely right about CPU-bound versus IO-bound! That's a great point. I should have called that out better in the video.

[@alijoumma]

@@TrevorSullivan thanks for you reply!

[@farzadmf]

Not to complain about your video (which is SUPERB), but, at least in the languages that I've personally seen, this is THE MOST unintuitive async programming code I've seen!

[@TrevorSullivan]

Thanks for your feedback! It can be a little bit confusing, I agree. Once you dive into the next video about implementing futures yourself, hopefully it will make a bit more sense.

[@farzadmf]

Sure thing; will check that out. This async stuff of Rust is one of those things that hasn't clicked for me at all!

[@atreeinthemoon]

Thanks for your video. I'm not clear why the thread sleeping longer returns first? when using the futures::select! ? In the output it prints out 12, 10, 8, ideally shouldn't it be 8, 10, 12?

[@shahidyousuf9464]

As per documentation, the macro; pin_mut! pins the Future on the stack. The futures here i.e num1, num2, num3 are pushed onto the stack in the order -> 8, 10, 12 and are popped in reverse order -> 12, 10, 8 irrespective of the sleep time on 12. Even on increasing the sleep time to much higher value, still it prints out in the order -> 12, 10, 8. Obviously due to stack used by pin_mut! macro.

[@alexperts5929]

what a great video man! thank you thank you!

[@TrevorSullivan]

@@alexperts5929 thanks Alex!! Enjoy writing Rust! 🦀

[@acatisfinetoo3018]

Is this the same as multi threading in other languages?

[@Gabriel-cv3cw]

No it is not. If you were spawning other threads on multiple cores like you would in other languages the various functions would actually run at the same time. For example, if you ran 4 functions each with a 1000 ms sleep multi-threaded then you could expect all functions to complete in around 1000ms together + thread overhead. Async/Concurrent code on the other hand basically passes the baton on a single thread for completing multiple smaller tasks so in the example of the 4 functions with the 1000ms sleep you could expect them to finish in 4000ms instead of 1000ms. Its usefulness is not really shown in real code in this video but basically you could in your main function start 4 different async tasks. When a task completes it queue up more async tasks, which when completed could queue up more async tasks. Because it is a queue and the start of each job is added before a job can complete, all tasks get to start before the first task completes and adds its second part/task. Hope this is helpful, I am learning rust and not very knowledgeable on async rust but I come from js which also has async await concurrency.

[@carminex]

No

[@sohansingh2022]

thank you!

[@test-y1p7r]

Hi Trevor. I'm not sure this code is functioning as you intended it to. I tried similar functions but with print statements and it seems like the code is executed synchronously. use futures::executor::block_on; use futures::join; async fn num1() -> u8 { println!("num1 started"); std::thread::sleep(std::time::Duration::from_secs(5)); println!("num1 completed"); return 8; } async fn num2() -> u8 { println!("num2 started"); std::thread::sleep(std::time::Duration::from_secs(5)); println!("num2 completed"); return 10; } fn main() { let _ = block_on(async { join!(num1(), num2()) }); } The output is: num1 started num1 completed num2 started num2 completed The issue seems to be the use of `std::threads::sleep`. I got the warning "Blocking `sleep` function cannot be used in `async` context". To turn the code into async, the compiler suggested replacing it with `tokio::time::sleep`. Changing the code to this solved the issue. use futures::executor::block_on; use futures::join; async fn num1() -> u8 { println!("num1 started"); tokio::time::sleep(std::time::Duration::from_secs(5)).await; println!("num1 completed"); return 8; } async fn num2() -> u8 { println!("num2 started"); tokio::time::sleep(std::time::Duration::from_secs(5)).await; println!("num2 completed"); return 10; } #[tokio::main] async fn main() { let _ = block_on(async { join!(num1(), num2()) }); } output: num1 started num2 started num1 completed num2 completed which shows the code is executed asynchronously.

[@TrevorSullivan]

Yes great point! Tokio has its own sleep function.

[@TheMatttm]

What theme is that?

[@TrevorSullivan]

Outrun by samrapdev

[@MateiAndrei94]

The first part is wrong. Asynchronous programming is not about making progress on multiple tasks so that it feels like progress is made on multiple fronts (or customers), it's about waiting. Imagine that in part 1 of the first project your worker has to wait a couple of days for materials to come. Doing the task synchronously would mean actually doing nothing while the materials arrive. Doing the task asynchronously would mean switch and start doing other work while the materials arrive.

[@solmateusbraga]

Looks like a lazy monad. Quacks like a lazy monad. Is it a lazy monad?