💻✅ Check out some of these links to upgrade your digital life! Thanks for helping support this channel! 🦀🦀🦀 💾 Crucial P3 2TB NVMe m.2 PCIe SSD amzn.to/464CXd9 📺 JSAUX 8k HDMI Cables 10ft 2-pack amzn.to/3PCTFto (I use these) 📺 JSAUX 8k DisplayPort Cable 6.6ft amzn.to/3Zuvz8p (I use these) 📱 JSAUX 100-watt USB-C to USB-C 6.6ft charging cables 2-pack amzn.to/3rw7NfF (I use these) 🪫 Anker USB-C 20-watt wall plug charger 2-pack amzn.to/44ZdbWs 👕 5-pack Assorted Workout Shirts for Men Short Sleeve Quick-dry amzn.to/3ESGKOI 💻 Samsung Galaxy Tab S7+ 12.4" 128GB Android Tablet amzn.to/3LBQOzp 🙂 (I have one, it's FAST, with a beautiful screen!) 🖥 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
📝QUICK CORRECTION: In this video, I mentioned that each iteration of the poll() method would be scheduled on a separate thread. However, it seems that the spawn() function schedules the entire future's lifetime on a given thread.
I found this video incredibly helpful! Thank you so much, Trevor. I love your teaching style and how you code from scratch. You do an awesome job explaining as you go, and this was the first Rust / Tokio video I've found that didn't confuse the heck out of me.
I have watched most of the videos in the Rust tutorial series and have much much appreciated them. The one minor thing I might suggest to Trevor is to maybe script the videos a little more. They all seem a bit more "seat of your pants" than most videos. That's potentially both good and bad. The bad is that sometimes dead ends are run into because not enough time was spent honing the procedures before coding them. That then leads to needing to backtrack or correct mistakes that happened. Potentially incorrect information is presented that then has to be fixed, hopefully later in the video. The good of this is that real programming tends to proceed just like that - lots of false starts, dead ends, and mistakes. By not covering up these slight errors and showing how he has to go back and fix things he is actually doing two very good things 1. showing that all programmers are human and mistakes happen 2. showing how to fix things when they go wrong. So, I'm a little on the fence as to whether the way the videos are constructed is genius or slightly sloppy. I'm leaning toward this format maybe being more good than bad because the process seems so genuine and relatable. Also, fixing mistakes may actually help to reinforce the correct way of doing things by showing how to fix slightly wrong ways of doing things. So, I hope this doesn't come off as negative. Actually, it's a kind of interesting way to present material that might even be better than honing the presentation to perfection like most people try to do.
Hey there, thanks for sharing your thoughts. I typically spend some time researching and testing the topics in planning to present ahead of time, to ensure they work and that I understand what I'm going to present on. You're right that it's not scripted out. Due to the rapidly changing software world, things do break sometimes, or maybe there's a concept I don't quite fully understand. This is just part of the style that's uniquely mine. I don't try to come across as everything being 100% perfect, and I also want people to see the somewhat random train of thought I have while building out an example. One day I might use cars as an example, other days I might use airplanes, or food, or people. This forces me to ensure I really understand the concept and can adapt it to different scenarios on the fly, rather than planning every single detail out ahead of time. It's much more relatable than simply copy pasting some code from another screen. That feels like "magic" and can install feelings of inferiority in the viewer; I want to avoid that.
I've also watched most of your videos, Trevor. Since I'm relatively new to Rust, I really appreciate how you explain the concepts and give examples. I know it might extend the video length, but if you encounter an error, instead of pausing and fixing it off-camera, could you share how you found the problem? Because the process of identifying and resolving errors can also be helpful for viewers. I think this aligns with your approach of making videos realistically. Alternatively, you could be a bit more prepared with the examples to avoid running into major errors that require stopping to figure out, giving viewers a clearer roadmap rather than showing them broken code that you then need to correct, which might cause confusion. 🥰
Thank you! I'm really glad that you are learning from these videos. I do usually try to understand things in advance to avoid too many errors during the videos. I will try to do a better job in the future of showing how I resolved errors.
You usually shouldn't use std threading stuff like sleep ( as you did in the first example) when working wih futures in tokio. Instead tokio provides its own utilities like tokio::time::sleep
completed_laps and self.laps are completely useless... you could just pop the Vec and match and decide whether to update the value then Poll::Pending, or just Ready. I'm a little puzzled why you did this...
I thought similar, but even though they're vestigial, I felt it did help drive the point home about how a future is a state machine, in which you can make whatever changes internally you need to to make it work. But yeah, it did add some unneeded cruft.
@@tiagomello thank you! I'm glad you appreciate that. I don't ever want to be perceived as a gate keeper. I typically reference the authoritative source for whatever topic we're covering. 😊
Great video but have to be careful! If you where to have only one CPU by your computer then sleep function would block all your spawn threads! That is the reason why they say that high CPU intensive work is better for parallel programming instead of async. That is because if you do not await you will be blocking other async work. Remember to use the tokio sleep function that has an await. Then that sleep function will hand work. That is the reason why you finally saw other threads on your computer finally being used.
Haha great idea! I'll probably start with Tauri, since Dioxus is based on it, as I recall. It'll probably be a little while before I get to those topics though, if I'm being honest. I'll keep it in mind though!
Thank you, Claudio! I know that 'return' isn't required in Rust, but I do like to be explicit and make my code more readable. Have fun writing more Rust! 🦀
It's VSCode with the Remote SSH extension to a Linux VM, running on LXD! 🙂 The first video in the Rust playlist covers the environment setup, and I also have a playlist that talks in depth about LXD!
Thank you very much! I'm glad you enjoyed this video. I have thought about it, but figured affiliate links might work better for people who are ordering stuff anyway. I appreciate the thought!
@@dmitriidemenev5258 I have spent most of my life programming in c++ (gave up on c++ post c++17) and for multi-threaded systems. Point in c++ and rust are trying to show off by adding complex features in a most complex possible way to the language. These language stay there and die a slow death. They day has come that there are 10 ways to code the same thing and people choose the hardest way making the code incomprehensible. Keep the language clean.
💻✅ Check out some of these links to upgrade your digital life! Thanks for helping support this channel! 🦀🦀🦀
💾 Crucial P3 2TB NVMe m.2 PCIe SSD amzn.to/464CXd9
📺 JSAUX 8k HDMI Cables 10ft 2-pack amzn.to/3PCTFto (I use these)
📺 JSAUX 8k DisplayPort Cable 6.6ft amzn.to/3Zuvz8p (I use these)
📱 JSAUX 100-watt USB-C to USB-C 6.6ft charging cables 2-pack amzn.to/3rw7NfF (I use these)
🪫 Anker USB-C 20-watt wall plug charger 2-pack amzn.to/44ZdbWs
👕 5-pack Assorted Workout Shirts for Men Short Sleeve Quick-dry amzn.to/3ESGKOI
💻 Samsung Galaxy Tab S7+ 12.4" 128GB Android Tablet amzn.to/3LBQOzp 🙂 (I have one, it's FAST, with a beautiful screen!)
🖥 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
📝QUICK CORRECTION: In this video, I mentioned that each iteration of the poll() method would be scheduled on a separate thread. However, it seems that the spawn() function schedules the entire future's lifetime on a given thread.
Very nice example! I feel it's only missing the use of join! macro at the end to show how we can idiomatically await the completion of the tasks.
I found this video incredibly helpful! Thank you so much, Trevor. I love your teaching style and how you code from scratch. You do an awesome job explaining as you go, and this was the first Rust / Tokio video I've found that didn't confuse the heck out of me.
Wow, thanks very much, Sam! I'm glad you've found my work helpful in understanding tokio. ❤️ Keep on coding! 🦀
Very well explained! Thanks
I have watched most of the videos in the Rust tutorial series and have much much appreciated them. The one minor thing I might suggest to Trevor is to maybe script the videos a little more. They all seem a bit more "seat of your pants" than most videos. That's potentially both good and bad. The bad is that sometimes dead ends are run into because not enough time was spent honing the procedures before coding them. That then leads to needing to backtrack or correct mistakes that happened. Potentially incorrect information is presented that then has to be fixed, hopefully later in the video. The good of this is that real programming tends to proceed just like that - lots of false starts, dead ends, and mistakes. By not covering up these slight errors and showing how he has to go back and fix things he is actually doing two very good things 1. showing that all programmers are human and mistakes happen 2. showing how to fix things when they go wrong. So, I'm a little on the fence as to whether the way the videos are constructed is genius or slightly sloppy. I'm leaning toward this format maybe being more good than bad because the process seems so genuine and relatable. Also, fixing mistakes may actually help to reinforce the correct way of doing things by showing how to fix slightly wrong ways of doing things. So, I hope this doesn't come off as negative. Actually, it's a kind of interesting way to present material that might even be better than honing the presentation to perfection like most people try to do.
Hey there, thanks for sharing your thoughts. I typically spend some time researching and testing the topics in planning to present ahead of time, to ensure they work and that I understand what I'm going to present on. You're right that it's not scripted out. Due to the rapidly changing software world, things do break sometimes, or maybe there's a concept I don't quite fully understand. This is just part of the style that's uniquely mine. I don't try to come across as everything being 100% perfect, and I also want people to see the somewhat random train of thought I have while building out an example. One day I might use cars as an example, other days I might use airplanes, or food, or people. This forces me to ensure I really understand the concept and can adapt it to different scenarios on the fly, rather than planning every single detail out ahead of time. It's much more relatable than simply copy pasting some code from another screen. That feels like "magic" and can install feelings of inferiority in the viewer; I want to avoid that.
I've also watched most of your videos, Trevor. Since I'm relatively new to Rust, I really appreciate how you explain the concepts and give examples. I know it might extend the video length, but if you encounter an error, instead of pausing and fixing it off-camera, could you share how you found the problem? Because the process of identifying and resolving errors can also be helpful for viewers. I think this aligns with your approach of making videos realistically. Alternatively, you could be a bit more prepared with the examples to avoid running into major errors that require stopping to figure out, giving viewers a clearer roadmap rather than showing them broken code that you then need to correct, which might cause confusion. 🥰
Thank you! I'm really glad that you are learning from these videos. I do usually try to understand things in advance to avoid too many errors during the videos. I will try to do a better job in the future of showing how I resolved errors.
38:18 check if its some variante and then unwrap has a good idiomatic method "and_then" that you unintentionally mentioned :P
You usually shouldn't use std threading stuff like sleep ( as you did in the first example) when working wih futures in tokio. Instead tokio provides its own utilities like tokio::time::sleep
completed_laps and self.laps are completely useless... you could just pop the Vec and match and decide whether to update the value then Poll::Pending, or just Ready. I'm a little puzzled why you did this...
I thought similar, but even though they're vestigial, I felt it did help drive the point home about how a future is a state machine, in which you can make whatever changes internally you need to to make it work. But yeah, it did add some unneeded cruft.
This is making so much click for me. Thank you! SUBSCRIBED.
I'm so happy to hear that! That's why I create these videos, to help people like you. 🦀🦀
Fantastic video, Trevor. Thank you!
I'm so happy it helped you, Tiago! ❤️🦀
By the way, I like the format, where you don't simply copy and paste things but instead guide the audience on how to find out things by themselves.
@@tiagomello thank you! I'm glad you appreciate that. I don't ever want to be perceived as a gate keeper. I typically reference the authoritative source for whatever topic we're covering. 😊
Great video but have to be careful! If you where to have only one CPU by your computer then sleep function would block all your spawn threads! That is the reason why they say that high CPU intensive work is better for parallel programming instead of async. That is because if you do not await you will be blocking other async work. Remember to use the tokio sleep function that has an await. Then that sleep function will hand work. That is the reason why you finally saw other threads on your computer finally being used.
Thank you for this video it is very useful to see a real example!!
Thank you! I am glad you enjoyed the example. I try to think of unique examples to use in all of my videos. 🙂
This is an amazing tutorial ..
@@azharuddin337 thank you Azhar! I'm so happy you found it useful. 🦀
🎉🎉 thnx for the gfeat daily vidros
I learned something 👍
Thanks! Next Tauri or Dioxus ?🙃
Haha great idea! I'll probably start with Tauri, since Dioxus is based on it, as I recall. It'll probably be a little while before I get to those topics though, if I'm being honest. I'll keep it in mind though!
Very good and instructive video!
Observation:
There is no need to use "return".
Thank you, Claudio! I know that 'return' isn't required in Rust, but I do like to be explicit and make my code more readable. Have fun writing more Rust! 🦀
Hi trevor. im trying to download some videos but i cant bc is encrypted can ou help me?
Thank you Trevor! Is it code-server on lxd vm?
It's VSCode with the Remote SSH extension to a Linux VM, running on LXD! 🙂 The first video in the Rust playlist covers the environment setup, and I also have a playlist that talks in depth about LXD!
Nice video Trevor. Have you considered adding a donate button to your channel?
Thank you very much! I'm glad you enjoyed this video. I have thought about it, but figured affiliate links might work better for people who are ordering stuff anyway. I appreciate the thought!
good technical video
subbed!
Just in time, I am writing an application using Tokio. I was looking over the docs today. And now this vid.
Thank you!! I am glad this video was released at just the right time for you. 🙂 Please check out the playlist! There's lots more coming, too!
really great video but please dont use such complex example. Here to understand future not f1 racer cars.
If c++ is -10 then rust is -100. Unnecessarily too complicated and will have the same fate as that of c++
Multithreaded asynchronous code is inherently complex. Are you sure your comparison apples to apples? What exactly are you comparing?
@@dmitriidemenev5258 I have spent most of my life programming in c++ (gave up on c++ post c++17) and for multi-threaded systems. Point in c++ and rust are trying to show off by adding complex features in a most complex possible way to the language. These language stay there and die a slow death. They day has come that there are 10 ways to code the same thing and people choose the hardest way making the code incomprehensible. Keep the language clean.