Your video didn't directly address the issue I was running across. But thanks for explaining this in more detail, because having that understanding helped me figure out the issue I was having. This is awesome Thanks so much.
I prefer smol/async-executor. It is much more lightweight and compiles like 10x faster. The only issue is that there are less libraries written for it then there are for Tokio, but this has not been that big of a deal for me.
Appreciate your hard work! Reading from file in async context does not boost performance, because OS generally does not provide async API, Tokio spawn a thread from thread pool to work with file.
You're correct, it's no faster than reading from a file normally, but allows concurrency due to the use of the thread pool. Which can be somewhat quicker as it need not create a new thread to do so! But the file operation is the same.
@@dreamsofcode quicker at coding, slower at runtime (I mean, what is the point of async, if it make your code slower) you can't mix async code with sync code... I like to call `spawn_blocking` on sync api...
The issues i have with c and c++ is the messy ecosystem and build systems. Rust seems to address both of these and tbh i don't find the code complex at all. I keep finding myself wondering when the hard part is going to appear.
Great content! I have one question regarding the futures though: If the future is only executed once await is called (generally speaking) that implies we would lose some performance here, would it not? Let's say we have an async database call. If we were to execute the call right away it might have completed already once we await it. But since execution is lazy it's only executed once we await it. This might not be a huge problem since we can use our resources for something else while awaiting the database's response (due to the use of a thread pool) but it would still add to our overall latency, would it not? Or do I have a fundamental misunderstanding of lazy execution in this context?
In the case that data is not ready for a future it goes into a PENDING state which will run a wake function when there is data available. Kinda like how u get mail when u hear the truck. Futures are designed to be incredibly efficient and zero cost
No u r on the right track btw In this case you can use join! macro to do other job while awaiting the db operation let (res, _) = join!(ur_db_operation, async { // ur other job here });
Tokio is not a framework, it is a runtime. There is huge difference between each other. Axum, rocket etc is frameworks and they depending on tokio runtime.
Wow. Appreciate the hard work in compiling all this information in a precise way. Thanks. Very refreshing.
Easily the best explanation ive seen on tokio. Thanks for this!
Thank you for the kind feedback!
Super cool video! I was confused about async in rust for a long time but could not find the great one like this. Thanks!
I'm glad you found it useful! Let me know if there's any other topics I should cover as well!
Same 😂
Wtf man. This content is pure gold!
Love the quality 🔥🔥
Thank you!
Your video didn't directly address the issue I was running across. But thanks for explaining this in more detail, because having that understanding helped me figure out the issue I was having. This is awesome Thanks so much.
Really glad to hear it helped! What was the issue you were facing? Maybe I can make a video about it :)
Great video.
Thanks for not begging me to subscribe, which I had already done half way through.
I'm sure RUclips viewers have been told to subscribe many times in their lives 🤣
This is the best explanation I have seen on tokio. Thanks for this!
Awesome guide to async! Please make the follow-ups for other tokio async modules. Thanks 👍
I shall do!
Fantastic intro, thank you so much!
That's awesome content. Thanks a lot for the effort you put into this
This is by far the best explanation of tokio, this is just fantastic. I love you man 💓
Aww thanks! I'm glad you liked it!
best explanation to tokio i've seen thank you
loving the rust content!
thanks, keep motivating us towards rust
Always!
Earned a sub man. Great video.
Thank you! Glad you enjoyed it!
I prefer smol/async-executor. It is much more lightweight and compiles like 10x faster. The only issue is that there are less libraries written for it then there are for Tokio, but this has not been that big of a deal for me.
Great video! I learned a lot!
Thank you! I appreciate the feedback. I'm looking forward to doing some more async Rust content!
Great content. Please do a video about structured concurrency in rust.
I've added to the backlog!
@@dreamsofcode awesome 🙂
Your voice here is way better than the current one
I'll rollback the firmware
Very nice. Thank you.
Appreciate your hard work!
Reading from file in async context does not boost performance, because OS generally does not provide async API,
Tokio spawn a thread from thread pool to work with file.
You're correct, it's no faster than reading from a file normally, but allows concurrency due to the use of the thread pool. Which can be somewhat quicker as it need not create a new thread to do so! But the file operation is the same.
@@dreamsofcode quicker at coding, slower at runtime (I mean, what is the point of async, if it make your code slower) you can't mix async code with sync code... I like to call `spawn_blocking` on sync api...
It is possible with io_uring (if you're running Linux)
Fantastic tutorial
Excellent stuff..
Incredible intro and channel. Have a sub! Thank you!
Thank you! I'm glad you enjoyed the video.
How did you made your terminal to this beautiful theme?
Ahh thank you, I use tmux + neovim + catppuccin theme!
In which web site you found this wallpaper?
thanks for this
2:20 if you build release mode, it seems it resolves it automatically
real good vid
The issues i have with c and c++ is the messy ecosystem and build systems. Rust seems to address both of these and tbh i don't find the code complex at all. I keep finding myself wondering when the hard part is going to appear.
Been starting at that code at 6:00, and I can't figure out how it sorts those strings.
@@gosnooky it uses systems sort command to to sort the words
Thank you
You're very welcome
Question: why rust doesn't have a std lib async runtime? Or is tokio better ?
huh, I tokio just provided a way to do async/await. I didn't know it had channels and green threads as well.
Great content! I have one question regarding the futures though: If the future is only executed once await is called (generally speaking) that implies we would lose some performance here, would it not? Let's say we have an async database call. If we were to execute the call right away it might have completed already once we await it. But since execution is lazy it's only executed once we await it. This might not be a huge problem since we can use our resources for something else while awaiting the database's response (due to the use of a thread pool) but it would still add to our overall latency, would it not? Or do I have a fundamental misunderstanding of lazy execution in this context?
In the case that data is not ready for a future it goes into a PENDING state which will run a wake function when there is data available. Kinda like how u get mail when u hear the truck. Futures are designed to be incredibly efficient and zero cost
No u r on the right track btw
In this case you can use join! macro to do other job while awaiting the db operation
let (res, _) = join!(ur_db_operation, async {
// ur other job here
});
Tokio is not a framework, it is a runtime. There is huge difference between each other. Axum, rocket etc is frameworks and they depending on tokio runtime.
The first two seconds the calls in a runtime. Haven't watched more to know if he slips up later, but yeah, you're right there's a difference
t’s a runtime in the same way people call react a library. In practice I’d say both are practically frameworks
It's literally a framework
TOOOOKIOOOOOOOOO
why did i read this in primeagean's voice?
In js async await makes functions synchronised, but in other languages it's opposite 😢😢😢😢
Don't I understand asynchronous programming?
someone tell me if and why this is an L take but shouldnt some of these features be in the std lib?
The fact that you have to use Tokio’s version of already implemented functionality on the std is really annoying.
This is great! Now, when to pin and unpin please :)
Reminds me a lot of Kotlin coroutines.
beeg?
at the same time != concurrently
Everything is great until you have async traits lmao