Can you check the email is going out. I submitted a request twice for the bootcamp and cheatsheet and didn't get email on either one. I checked the spam folder already. 😁Thanks.
You make the best videos on Rust I've seen. Most others, even on this specific subject, just talk fast and gloss over dozens of things, whereas you explain things as if you actually want me to have a chance at writing this code myself later. Thanks for the quality content!
i watched a lot of videos and have read a lot of tutorials but all of these tell about “how to implement an echo server with tokio”, bot explaining how it works. your video in a few minutes explains perfectly how it works.
A very clear description of the tip of the iceberg. I've finally sat through Jon Gjengset's videos and my head is full to bursting. Keep going, these are great.
Woah, excellent explanation of the async workflow! I always got confused with the tokio stuff, but you've built it up so nicely that it made perfect sense by the time it came up in the video!
Thanks! Answers a lot of questions for me at the point where I am now. I'm coming from many years of working with C# (and several other languages, but async await is especially important in C#). I have started learning Rust and I've alread gone through the entire official Rust book too (which comes with a manually written ThreadPool example with a mini HTTP server), but that doesn't talk about async await yet. I really like that you can configure the threading behaviour of the tokio library. In C# this behaviour is much more contextual, based on whether you have a so called SynchronizationContext, which is the case in UI frameworks, but not in console applications. In a UI framework you get single threaded behaviour by default for async code, so that you get less issues with cross thread access on the UI, but the risk on deadlocks is higher if you do things incorrectly. Though sometimes you want to configure things per method call, in order to overrule that single threaded continuation behaviour. Does Rust or the tokio library also serve an equivalent of ConfigureAwait?
It's late at night, I am sleepy af and struggling with the words like async/await. Now I realize how beutiful you explain. It is a work of art, and a fine one if I say so myself.
This was so helpful! I was so confused that async is a rust keyword but then everywhere they tell you need some runtime as a crate, since it is not part of the std. Like what? Very confusing for a beginner, but your video explained this greatly! I would like to see more videos about these kind of interactions, maybe how the microcontroller ecosystem is build with HALs etc if you know more about that :)
This was a very clear guide to the basics, I was struggling with why I needed something like tokio. Opening new threads, channels makes since to not block the main thread.
@@danvilela Async code is easy in Go compare to rust, its less verbose, but one thing problem in Go there is a chance of the code ending up in race condition and importantly some issue related to threading gets caught only in runtime in Go which is a extremely costly when u have things in production, Coming to rust, Compiler is extremely strict and if the code gets compiled without any issues for sure 99% there will not be issues in the runtime which is fantastic for rust and race conditions is no where possible in rust.
@@elnur0047 just a novice myself, but it depends on the runtime you choose, I believe. Tokyo in this case but there are others. And he actually mentions in the video that Tokyo uses a thread pool to run the tasks, so it should enable real parallelism.
It is quite amazing that a low level language can do the stuff c# does. As a Microsoft specialist I wont be programming Rust anytime soon for my clients but it is certainly nice to know that this kind of stuff is possible.
Thank you for providing a glimpse of running native async functions using the community's best runtime Tokio. Could you make a video on "streams and select ", these are quite confusing and I don't see documentation doesn't cover them in a straightforward way, ur videos on these could be a great help ........Thanks again for the amazing content.
love your channel. i was always intrested in rust. but with your videos i feel like i have to use it for everything. its such a nice language. not easy, but really nice. i usually program in python for work. but hope to introduce rust for other stuff in my company
Thanks so much...for those like me beginning async in Rust, you helped a lot. Made so much easier as you point out parallels with generally more familiar languages (for Rust newcomers). Perhaps worth noting is that React similarly doesn't let you call await unless the function is async. Loved the intro to Tokio illustrating how it solves a previously unmet need.
Great video, as usual. Even when it's a concept I already understand, I appreciate the refresher with a clear communication style. Unrelated, but I want to ask if you have been working on your accent? With each video it becomes more indistinguishable from a regular American accent. I'm just curious if that is natural, or if it is intentional? Pretty good, either way!
Is there an equivalent of the .then JS syntax ? If you don't want to await but you want to execute some code after the future returned how do yoy do it? Do you need to create an async function and call await there as you did in the video?
Great! this will take a bit effort to absorve. I tried an experiment with read_from_database and generated a random number using rand library to use as argument in sleep method. But rust started complaining as it said 'mut rng' of Rng does not implement Send traid and can not be passed across threads.
Great video! One thing I didn't understand was why I should not put performance intensive calculations in async functions. Obviously if I'm using the single threaded mode (flavor=current_thread) then yeah it'll hold up the entire event queue, but if it's multithreaded then other threads can continue executing while the calculation is being done. Any help would be appreciated! 🙏
If you run long running task on async task, it will prevent another task in same worker(thread) to make progress. In tokio, There is two option to run long running task without impacting overall performance. 1. block_in_place: It will move every task in current worker thread to another worker thread but self. 2. spawn_blocking: It will move long running task to dedicated blocking thread pool and put current task into sleep until long running task completes.
In C++ you can spawn a task (or just return one from a function) with std::async and C# has its own executor to spawn a new task as soon as you call an async method, rust takes both of them to make it more verbose and pointless, so i'm still tryna understand the real benefits of using async/await in Rust and not just simple thread spawning as in C++
There's absolutely no benefit to using rust over c++ unless you don't understand allocating memory. You would think with rust being a modern language it would make things simpler and cleaner than c++ but the opposite is true.
@@SumoCumLoudly I'd say the opposite, there's simply no point in using C++ in almost any scenario rather than using Rust, it's just dumb and needlessly bugging you.
@@SumoCumLoudly saying that you can code as safe in c++ as in rust by "understanding allocating memory" is undermining the fact that the majority of bugs to this day come from poorly managed memory. Even the top c++ gods write memory leaks amd out of bounds errors period. Thinking that you can write programs that are somewhat bigger than a student works in c++ without creating a single memory error somewhere is ludicrous. Many of the leading tech companies call c++ a sinking ship while simultaneously rewriting buggy c++ code in rust.
@@SumoCumLoudly Why make your life more difficult worrying about memory management in C++, when you can simply use Rust and let the compiler tell you how to write safe code?
Its odd to me that the keywords in the language can't be utilized within the standard library, and we need a community led package to use. I do see the mini_tokio implementation, but why can't this be in the std lib?
You say you shoulnt put cpu intensive operations in async code. lets say have a big list of elements that need to be processed. Is making my function that processes them async and sending slices of the list to it so it runs can run concurrently a bad idea?
Having to add a dependency just to add async code kinda sucks, doesnt it? Im new to Rust, comming from c#. I know its a minor thing, but i like to keep my dependencies as few as possible, and i dont realy see why this isnt in the base rust functionality? A Explanation would be great, cause i dont see how this makes sense tbh.
4:50 you describe await as a callback to the executor. I might be mistaken, however I seem to be told that the executor polls rather that establishing a callback... ??
From what i understand. With this you can run non blocking functions concurrently without thread spawning costs, no worry about scheduling, with code that looks just like the single thread ine.
Call me crazy but you still have to await the “handle” to get the result of the async function. So wrapping them in tokio::spawn() is just extra boilerplate when you could just write my_function().await which you also still have to do inside of tokio::spawn() anyways. The only thing tokio seems to be actually doing is wrapping the future in a result
As far as I understood it Tokyo spawn takes a (lazy) future, starts running it without returning control flow to the caller allowing you to start other work that runs in parallel to the started future (potentially another future). Awaiting 2 futures after another is running the 2nd after the first completed. Running 2 futures with Tokyo spawn will start their execution simultaneously making them run at the same time and then collecting the result of the 2 parallel run futures when awaiting their handles.
The static lifetime on the async has bad usability. Ease of debug was bad as well. The main purpose of async / await was for no wait I/O, and you just as well use such a no wait IO crate directly.
Can you create or, if you already have, or is to a video with an example of how to for and forget tasks? Also when you use async move, when the type is not Send, it’s not that easy (having this kind of trouble right now)
Newb here: at 9:55, when calling tokio::spawn(..) why is there a need to use the async move block? Isnt' tokio::spawn(my_function(i)) a legal call? my_function already is a future.
Hi, how to test those async functions? Let's say i have a module with some async functions which I'll use into my web-server (actix) service. How to test them independently?
I'm learning (or watching at least) rust with you. I don't know if it will be the super future language or not, but you keep me entertained. I need some more practical courses, do you have other practical courses? like some ebook or udemy? It will be a good idea!
tokio mentions that the sleep function is limited to a millisecond granularity. What would you use to sleep for microseconds? i looked at tokio-timerdf but there's very little examples and i'm quite new (fyi, running on linux) thanks
You need to understand the control flow of calling sleep : Sleep is awaited Sleep finished and calls the wake method of the Tokyo runtime Tokyo registers that the future in which sleep was called should now be pulled again to execute the code after sleep. This happens (likely) by enquing the future in a queue that the Tokyo runtime is working to clear. By stepping through this you can see that there are multiple points where the duration it takes to execute the things after sleep can be delayed by things unrelated to sleep and you current function (like other awaited futures in the set queue before the sleep one). In short you cannot predict how long it will take sleep to return exactly and the tokyo team decided that a finer grain of delay is impossible to guarantee. Imagine waiting for 5.05 milliseconds and then being stuck in the queue for a minimum of 1 millisecond. What is the point in these 0.05 milliseconds then?!
Because it's still just programming code, the benefits of asynchronous programming is that you can "wait" and thereby leverage all threads in an equivalent way, if you run a lot of sequential code (no await or yield) in an async method it will be basically blocking a thread for a long time
Bc async is ment to share execution time between all async functions. If you have cpu intensive tasks you should spawn a new thread in order to use another core of the CPU.
whenever I type in these programs I get errors. For example, I have exactly what you show but I get an error trait Future { type Output; fn poll(&mut self, wake: fn()) -> Poll; } enum Poll { Ready(T), Pending, } fn my_function() -> impl Future { println!("I'm an async function"); } Same code as far as I can tell, but VC Code is underlining the "impl Future" saying the trait `Future` is nit implemented for `()`. This type of error is in almost every program I type in. I wish there was source code I could paste in to avoid typing errors. Why do none of the examples work? Guessing game worked but i had to make a few changes. I am on cargo: cargo 1.61.0 (a028ae42f 2022-04-29) and rustc: rustc 1.61.0 (fe5b13d68 2022-05-18). I really want to use the language but none of your examples work correctly. Do I have something misconfigured? This is driving mr crazy!!!
likewise can someone recommend example tutorials where the code works and has sample code to paste in? I like Bogdan's style but literally none of the programs work without some bizarre error
Not a tutorial, but the Rust books have great examples. They walk you through pretty much the process of how the code is how it is so you may get a feel on it. For async, I’d recommend reading the Asynchronous Programming in Rust book. It’s a pretty solid guide to async in Rust. It’s pretty short and concise
@@nayyaraairlangga321 Thanks man. I haven't bought that one yet. I'm old school and still enjoy using a good old fashioned book to learn new languages. But I wonder why whenever I type in one of LetsGetrusty's code from off his screen it is always not working quite right. I would love to find typed in code to see if there's something I mistyped but don't see. That is usually the root cause
Why tokio::spawn takes ownership of the i variable? I mean, i is allocated and assigned to 0, then spawn takes the ownership of i, so i is no longer valid for the next loop iteration, meaning i may be pointing to a nullptr or the memory region that is already in use.
Here is an unpopular idea - maybe someone someday will show how to use async Rust without libraries in the real world?.. Because at this point all videos can be broken down to tokio advertisement rather than actual async Rust. General idea for async/await is more or less the same for all languages, the difference only comes down to built-in runtimes and rust doesn't have one. Tokio is great, but it is not the best solution for every project and it would be really nice to learn different approaches for using async Rust or writing own single and multithreaded runtimes.
Спасибо за видео. Если не трудно, мог бы ты делать субтитры на русском? Русскоговорящие бы в таком случае смогли бы и английский подтянуть, и лучше воспринимать информацию. Был бы очень благодарен:)
