To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/fasterthanlime/. The first 200 of you will get 20% off Brilliant’s annual premium subscription.
I put away rust for a lil while then chose today to come back and look at async. And by some huge coincidence, you post an async video! Truly a christmas miracle
@@fasterthanlime It's definitely not your fault! Just poor knowledge of subject matter on my part. I've written some Zig over time, but almost no Rust of my own, so while I mostly understand memory-related things, I don't fully grasp Rust-specific things very much. It's still fascinating to watch you deep dive, which is why I keep watching even if I don't fully understand. This comment was in light spirit. Thank you for doing your best! :)
I'm looking forward to seeing Rust's async functionality develop, but I also understand it's a very difficult problem to solve for a systems programming language. The challenge, compared to something like Go, is off the charts. If the team somehow manages to make it easy to use over time, that'll be noteworthy!
May be you see it is complecated, but boy you'd have to try async before 2018, before actual introduction of async keyword! That was complecated and compiler errors wasn't very nice either! So, current state can be improved but it is totally usable and pretty decent with latest versions!
Having not followed Rust for several years, i got a pleasant surprise to hear that GATs were stable! 😅 Also async fn in trait is cool too. Thanks for the video!
The tower future is more flexible but requires you to Box your future or name your future which then requires you to implement your own Future (and probably pull out the pin-project crate) and the logic of the service shifts to the future implementation. I'm not aware of a (near) perfect solution but this is pretty daunting for first time users.
@@fasterthanlime Ah I missed that! So there's no limitation? You can impl the call method with an async block and your future associated type be impl Future + Send + 'a?
I hope one day associated consts of trait implementations also become dyn-compatible. Currently you just need to make a companion dyn-compatible trait that has a method for getting the const value. Sure, it's not actually CONSTANT as in compile-time constant (from the caller point of view) but it would be very useful and de-clutter code. I think it would make sense to put have that in the vtable as well. And taking owned self is usually worked around on by marking the method `Self: Sized` (so it isn't available in trait objects) or by making it take `Box` (or other smart pointers), which is pretty clever.
Pretty sure async is the last bit of rust I haven't touched yet, hope it gets simpler by the time I get around to it. But then again I haven't yet really needed to write anything that has functions that wait for a bit and need to give way.
It definitely has gotten a lot simpler, you can see the whole history over at areweasyncyet.rs - writing futures manually was the only option in the beginning, and now there's really no reason to do it!
Yup! I ran into it in the first draft of this article but not in the rewrite. I might touch on it in the future, especially with the upcoming Rust 2024 edition! (coming February 2025).
I love these videos, and I've been in and out of rust for years. After doing a project in C# with linq and cosmos, it's so difficult to consider another project in rust just with ease of use alone. I could say similar things about swift. Having async stabilized like this is a huge boon for rust, I really look forward to seeing more progress. I hope the rust foundation gets comfortable enough to visit older STD libraries to smooth them out, some of them have quite a bit of bloat or cost associated with them that really require alternate packages.
Hey! Thanks for the videos! They are cool and very detailed! One thing I find myself doing is that switching to 0.75 speed of pressing pause too frequently, because I can't even grasp what was in code block you've showed! So, I think running with a bit slow pace and showing code for a bit longer would benefit the joy of viewers like me who should constantly rewind and pause the videos! Thanks anyway for the great content!
For a while now I've been actually using async rust in production (in a embedded context no less! embassy-rs ❤) and it has been an interesting (sometimes painful) journey to see the compiler support get better. For me it has been a recurring thing theme hitting the bleeding edge of what my main language development language can do so with C it was painful, but eith Rust it has been liberating how fast what I thought not possible has been made possible (GAT was a very welcome recente addition). For now besides async I'm mostly at how decl macros 2.0 are coming along, because you can do so much with the current system, but it seems like it could do so much more in the future (without requiring a whole separate crate to do procmacros).
The async traits feature was added along with opaque return types in traits, so the last blocked must've been making opaque return types work in traits. Just a neat observation.
Stacks grow downward because it makes the math easier. Replace up and down with left and right and it’s easier to understand, if the stack grows upwards (to the right) then the top of the stack represents the last usable address in the stack frame, but actually that address is not usable because if you put a value there it is by definition going to start at the end of the stack and continue rightward (past the end). This means that that address is not actually usable, you need to do some math to make sure your last element (along with its total length) all fits before the end of the stack. If your stack grows downwards (to the left) then that address is usable because anything allocated there will extend to the right.
At 13:25 you talk about a breaking change that would need to be implemented. Has anyone brought this to the attention of the contributors for Rust 2024 edition? I really hope Rust is taking the opportunity to make the needed changes to advance the language.
Ok... I'll keep fiddling around with go because I won't be able to convince anyone else learning these concepts, problems & solutions. Including me. I know stuff in theory but using it on a day to day basis & creating maintainable code. I have time & skill issue there. Interesting though.
The good news is that Rust beats go at its own game in the message-passing/actor-model with pattern matching against enums. And when doing that, async is just unnecessary.
The problem is that each of your dependencies have to be written for the same version of the same runtime to be used in the same context. I know about those other runtimes. More runtime doesn't help this problem at all.
@@JG-nm9zkif by same version you mean same major version, sure, but that's hardly a big deal. The fact that some leaf tasks are executor specific is why there can be multiple executors, so it's a tautological problem: you have the problem of multiple executors because you have the benefits of multiple executors. You may as well complain about having both integers and floats. Mixing and matching isn't even hard, you pretty much just have to spawn(async {}).await, or the like. In general if you don't want to care about this, just use tokio libraries because I've yet to see a case where there wasn't one.
Been getting rusty on rust lately lol i started aoc in rust and only made it to like problem 6...i did do aoc cybersecurity tho lol i have a lot of fun with rust but still not 100% comfortable with it yet tbh
Thanks for sharing such valuable information! Could you help me with something unrelated: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How should I go about transferring them to Binance?
None of this words are in the Bible. I was interesting watching this video. I tried rust for a few months, I think I got the problem being solved but I don't understand the solution properly.
@@ankur-dhama lol rust doesn't want a runtime or have an abstraction-scheduler over os threads, runtimes in embedded like embassy or rtic that are interrupt driven async runtimes wouldn't work for that. You are comparing rust with solutions for languages that are not targeting system level or embedded software.
@@l-const Rust is a general purpose programming language, not just a systems programming language. Go like green thread solution can be really useful in application development use cases.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/fasterthanlime/. The first 200 of you will get 20% off Brilliant’s annual premium subscription.
hey, hope you are doing great.
Great to see you again
@@romanstingler435I actually am, thanks for asking! Happy holidays!
I put away rust for a lil while then chose today to come back and look at async. And by some huge coincidence, you post an async video! Truly a christmas miracle
Literally the same
I always watch these while understanding nothing
I uhhhh.. I will try to do better. Thanks for coming back! 🫡
@@fasterthanlime It's definitely not your fault! Just poor knowledge of subject matter on my part. I've written some Zig over time, but almost no Rust of my own, so while I mostly understand memory-related things, I don't fully grasp Rust-specific things very much. It's still fascinating to watch you deep dive, which is why I keep watching even if I don't fully understand. This comment was in light spirit. Thank you for doing your best! :)
I'm looking forward to seeing Rust's async functionality develop, but I also understand it's a very difficult problem to solve for a systems programming language. The challenge, compared to something like Go, is off the charts.
If the team somehow manages to make it easy to use over time, that'll be noteworthy!
May be you see it is complecated, but boy you'd have to try async before 2018, before actual introduction of async keyword! That was complecated and compiler errors wasn't very nice either! So, current state can be improved but it is totally usable and pretty decent with latest versions!
@ZekeFast I'm well aware of how things were back then, and the situation has obviously improved. But it could always be better.
This is an espresso shot of Rust knowledge, delicious!
Hopefully return type notation gets stabilized soon so you'll be able to add those Send and 'static bounds on the caller side.
Do you have a link to what it's going to look like?
RFC 3654
Having not followed Rust for several years, i got a pleasant surprise to hear that GATs were stable! 😅 Also async fn in trait is cool too. Thanks for the video!
It's been a long time coming but several things have been fast-tracked for stabilization recently - feels good!
Bbno$ at home.
Happy holidays
lol
The tower future is more flexible but requires you to Box your future or name your future which then requires you to implement your own Future (and probably pull out the pin-project crate) and the logic of the service shifts to the future implementation. I'm not aware of a (near) perfect solution but this is pretty daunting for first time users.
The video shows a third solution (TAIT), but yeah, all off it is probably daunting, good point!
@@fasterthanlime Ah I missed that! So there's no limitation? You can impl the call method with an async block and your future associated type be impl Future + Send + 'a?
I hope one day associated consts of trait implementations also become dyn-compatible. Currently you just need to make a companion dyn-compatible trait that has a method for getting the const value. Sure, it's not actually CONSTANT as in compile-time constant (from the caller point of view) but it would be very useful and de-clutter code. I think it would make sense to put have that in the vtable as well. And taking owned self is usually worked around on by marking the method `Self: Sized` (so it isn't available in trait objects) or by making it take `Box` (or other smart pointers), which is pretty clever.
Missed these videos!!
Pretty sure async is the last bit of rust I haven't touched yet, hope it gets simpler by the time I get around to it. But then again I haven't yet really needed to write anything that has functions that wait for a bit and need to give way.
It definitely has gotten a lot simpler, you can see the whole history over at areweasyncyet.rs - writing futures manually was the only option in the beginning, and now there's really no reason to do it!
I appreciate your content, thanks man!
I’m glad!! Enjoy!
I was expecting a mention of + use, which I haven't had a chance to use yet but is apparently about specifying lifetimes for futures?
Yup! I ran into it in the first draft of this article but not in the rewrite. I might touch on it in the future, especially with the upcoming Rust 2024 edition! (coming February 2025).
I love these videos, and I've been in and out of rust for years. After doing a project in C# with linq and cosmos, it's so difficult to consider another project in rust just with ease of use alone. I could say similar things about swift.
Having async stabilized like this is a huge boon for rust, I really look forward to seeing more progress. I hope the rust foundation gets comfortable enough to visit older STD libraries to smooth them out, some of them have quite a bit of bloat or cost associated with them that really require alternate packages.
Hey! Thanks for the videos! They are cool and very detailed! One thing I find myself doing is that switching to 0.75 speed of pressing pause too frequently, because I can't even grasp what was in code block you've showed! So, I think running with a bit slow pace and showing code for a bit longer would benefit the joy of viewers like me who should constantly rewind and pause the videos! Thanks anyway for the great content!
For a while now I've been actually using async rust in production (in a embedded context no less! embassy-rs ❤) and it has been an interesting (sometimes painful) journey to see the compiler support get better.
For me it has been a recurring thing theme hitting the bleeding edge of what my main language development language can do so with C it was painful, but eith Rust it has been liberating how fast what I thought not possible has been made possible (GAT was a very welcome recente addition).
For now besides async I'm mostly at how decl macros 2.0 are coming along, because you can do so much with the current system, but it seems like it could do so much more in the future (without requiring a whole separate crate to do procmacros).
I really hope Async Rust gets more attention as I believe it is such an important feature nowadays. Maybe this and variadics
"to be static, to be owned, to have potentially infinite life"
The async traits feature was added along with opaque return types in traits, so the last blocked must've been making opaque return types work in traits. Just a neat observation.
damn, thanks for the vid, finally another great rust channel 🙂
Stacks grow downward because it makes the math easier. Replace up and down with left and right and it’s easier to understand, if the stack grows upwards (to the right) then the top of the stack represents the last usable address in the stack frame, but actually that address is not usable because if you put a value there it is by definition going to start at the end of the stack and continue rightward (past the end). This means that that address is not actually usable, you need to do some math to make sure your last element (along with its total length) all fits before the end of the stack. If your stack grows downwards (to the left) then that address is usable because anything allocated there will extend to the right.
At 13:25 you talk about a breaking change that would need to be implemented. Has anyone brought this to the attention of the contributors for Rust 2024 edition? I really hope Rust is taking the opportunity to make the needed changes to advance the language.
I've listened to a few episodes of the podcast, but had no idea it was you on it until now 😂😂
That’s hilarious
This video was the best christmas gift I could've gotten. Thanks!
Merry Christmas :)
This it too fast for me to digest. 😵💫
The article form is available on the website :) You're also welcome to lower the video speed or pause to read the code on-screen.
I feel stupid
Ok... I'll keep fiddling around with go because I won't be able to convince anyone else learning these concepts, problems & solutions. Including me.
I know stuff in theory but using it on a day to day basis & creating maintainable code. I have time & skill issue there.
Interesting though.
The good news is that Rust beats go at its own game in the message-passing/actor-model with pattern matching against enums. And when doing that, async is just unnecessary.
@haydenflinner why are ther 17 actor frameworks then?
@@deado7282 cause you don't need an actor framework
what if we could add bounds to functions in traits? ```rust
trait Foo{
async fn bar(&self) + Send + Sync + 'static -> i32{
...
}
}```
That's basically what RTN (return type notation) is github.com/rust-lang/rfcs/blob/master/text/3654-return-type-notation.md
i wish they can fix all these async rust issue. idc if breaking change has to be made here.
where are your cat ears?
I keep my cat ears were nobody would look for them: on my two cats.
>Pin dyn Box Async Meme String
🎹🎹🎹 💯💯💯
😌😌😌
There are still fundamental problems with rust async. What color is your runtime? Not only what color is your function?
I mean isn’t it a universal problem though?
Where some see problems, others see flexibility! tokio is not the be-all end-all, see monoio, glommio, etc,
The problem is that each of your dependencies have to be written for the same version of the same runtime to be used in the same context. I know about those other runtimes. More runtime doesn't help this problem at all.
Not with the go keyword with channels but I guess it's too much overhead for rust@@us4tiyny4n
@@JG-nm9zkif by same version you mean same major version, sure, but that's hardly a big deal.
The fact that some leaf tasks are executor specific is why there can be multiple executors, so it's a tautological problem: you have the problem of multiple executors because you have the benefits of multiple executors. You may as well complain about having both integers and floats.
Mixing and matching isn't even hard, you pretty much just have to spawn(async {}).await, or the like. In general if you don't want to care about this, just use tokio libraries because I've yet to see a case where there wasn't one.
Been getting rusty on rust lately lol i started aoc in rust and only made it to like problem 6...i did do aoc cybersecurity tho lol i have a lot of fun with rust but still not 100% comfortable with it yet tbh
what song is playing in the first 15 seconds of this video
Thanks for sharing such valuable information! Could you help me with something unrelated: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How should I go about transferring them to Binance?
None of this words are in the Bible. I was interesting watching this video.
I tried rust for a few months, I think I got the problem being solved but I don't understand the solution properly.
I never authorized this video.
This language is such an eye soar, its like looking at chicken scratch
*eye sore
Yo, i didnt know bbno$ had a coding channel.
mom mommm!!! it's Iosevka time
I tried to switch to Berkeley Mono but Iosevka is back by popular demand
Rust is the language of CS politics.
Async has always been a mistake everywhere. It is an antipattern that infects libraries and bubbles up everywhere.
What is the alternative?
@@PaleyBlog Go has the alternative, essentially using the idea of "green threads".
@@ankur-dhama lol rust doesn't want a runtime or have an abstraction-scheduler over os threads, runtimes in embedded like embassy or rtic that are interrupt driven async runtimes wouldn't work for that. You are comparing rust with solutions for languages that are not targeting system level or embedded software.
@@l-const Rust is a general purpose programming language, not just a systems programming language. Go like green thread solution can be really useful in application development use cases.
Thanks for the Christmas gift 😊 are we going to see you at RustNL/RustWeek in May? "No spoilers" is also a valid answer 😉
I’ll be there!!