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!
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!
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.
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.
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?
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.
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 :)
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.
@@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.
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
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.
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!
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?
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... ??
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?!
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?
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.
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.
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)
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?
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.
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?
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.
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
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
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.
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.
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.
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!
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.
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.
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?
📝Get your *FREE Rust cheat sheet* :
www.letsgetrusty.com/cheatsheet
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.
A sink and a weight are things you find at a gym.
Also rarely spawns in houses
A sink and a wait are things which you have while fishing.
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!
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.
Love how you breakdown the concepts here. Really enjoyed it.
I know this video is two years old but it was really well done. I liked the presentation format with the sample code. good job.
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!
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.
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.
Can you show us how to make an implementation of what a simple runtime might look like. Otherwise great video
If you look for the "async" page on the Tokio tutorial, it will teach you how to write a minimal runtime.
I second this!
@@riccardot I was just about to ask this... thanks!
Best async await video on the www
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?
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.
Thanks for the in depth explanations and not only showing how it can be done :)
I appreciate the great explanation on the feature and how to properly use it. I am looking forward to the bootcamp. Thanks.
Very informative. Now I finally understand what async really is.
tokio = { version = "*", features = ["rt-multi-thread", "macros"] }
to reduce compilation time
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 :)
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.
"Perhaps worth noting is that React similarly doesn't let you call await unless the function is async." He does note that, I think more than once.
@@dartme18 I thought you were gonna make a remark on how they said "React" and not Javascript...
@@mitigamespro8757 You're right, await is a javascript mechanism, not react 😀
him: in this example we have two functions
me: whoa slow down there
Flawless explanation! Really great video. Thanks a lot 🙏
What a great video Bogdan, keep it up!
Just like I always say, Async Rust makes Multi-threading look easy
better than go? just want to know
how is it making multi-threading look easy when it pretty much runs on a single 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.
Thanks for the content. A video about dependencies management (versions, futures) will be great.
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.
Huge thanks for such awesome video, i will be waiting for advanced async code in next video!
what is the point of having async functions in standard library if they can't by default be executed asynchronously
Requested it a few days ago perfect timing thanks a lot
Whenever I see this "async" polluting codebases, I feel thankful for the simplicity of the "go" keyword.
It is not pollution
@@diadetediotedio6918it's is. You have to rewrite from bottom to top just because you want a single async function
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
Excellent explanation 🚀
Wonderful! Looking forward for more Tokio sessions. Thanks.
amazing content, thanks Bogdan!
Fantastic content
Aren't we all just awaiting the future....
Looks Sync to me
Nicely explained, thank you.
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.
follow-up question - what about the state / future of generators?
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!
The for loop in lines 15-17 (for handle in handles) makes me think you're sequentially calling await. How does it execute concurrently?
It doesn't (idk but I think his code is synchrony)
Very good video indeed.
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?
nop
I straight up will never get over how the guy pronounces "cheet sheet"
Is it possible to use a debugger with asyc rust, and have breakpoints get triggered inside async functions?
I was hoping for a bit more showing how the actual runtime/executor works. Like how does the polling process actually work?
Thanks a lot man!
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... ??
thanks!
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?!
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?
Awesome! Moar asyncio!
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.
@@David-x7u6k Very good question and answer too, I had the same problem. Thank you.
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.
What is your opinion to async_std?
Good video !
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)
My nodejs brain was doing fine, until you started getting all concurrent 😂
Great video though, helps a lot!
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?
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.
How do you get realtime error side to your code, i can't seem to make vs code check my code more than only on save
When you say "concurrently", did you mean "running parallelly in threads" ?
Nice, but how is this different from a regular thread oriented program?
Thank you 😊
I'm curious why the await functionality is used by syntax future.await not await future
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.
spawning threads is expensive. If you have many tasks which are IO bound, asyinc/await will be faster than if you spawn a thread for each.
@@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?
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.
Are async closures still unstable?
Which are the reasons for not wanting cpu-intensive code in async functions?
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
Thanks!
Why there is a *move* keyword at closure async function?
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
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.
Why should we not put cpu intensive tasks in async functions?
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.
They got some inspiration from C#
I dont understand the await/async is nessesary for this. Using threads/tokyo should add the concurrency. Why was the async and await nessesary.
Same question
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.
@@affegpus4195 oka i think that makes sense thx
its a bit strange that rust has async and await built in, but not an async runtime.
2:16 giggity
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!
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.
must make a video on async streams with tokio
go into shortcuts in tNice tutorials video. They are not technically linked but it's close. I do wish there was a way to completely link them
u need to add error handler
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.
Looks like Rust is a language where you have to memorize so so much what one tiny statement does - isn't is a big disadvantage?
More async stuff
Sounds a lot like C#
Ничего не понял, но очень интересно.
С какой целью ты смотрел видео? С чисто художественной или с образовательной (изучение языка rust)?
These inlay hints of visual studio are always so annoying.
Ha polled to completion
Спасибо за видео. Если не трудно, мог бы ты делать субтитры на русском? Русскоговорящие бы в таком случае смогли бы и английский подтянуть, и лучше воспринимать информацию. Был бы очень благодарен:)
Здравствуйте. Вы можете скачать яндекс браузер и слушать видео на русском языке)
А что этот мужик знает русский язык?
@@tomburg2 он Украинец
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.
he pretty much said that you need a runtime to make it work. The language doesn't provide its own async runtime, just a way to call them
он русский?
cringe
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?