📝Get your *FREE Rust cheat sheet* : www.letsgetrusty.com/cheatsheet Correction: The second limitation of this new nightly feature is that you can not spawn *from* a generic function while using a work stealing executor that requires spawned tasks to be Send. Note that the Rust team thinks this situation will be uncommon.
GAT -> async trait, the Rust team always has a super clear and steady path. I've never seen a team that ships software like this, especially in those "best FE framework" variety shows.
baremetal embedded programmer here: we avoid std lib BECAUSE of heap allocation. Managing the heap is a pain, while having all in stack and static and without using recursive function, means we know ram and stack usage at compile time, and guarantee no leaks even on C/C++. Very important for devices the MUST work, sometimes for years between reboot
@@Stopinvadingmyhardware you can check the ESP32 chip environment in rust, it can be with or without std. Oh, and Linux had branch to run stm32f4 and f7, that are the most common MCU at least between hobbist. After all some model are dual code and have more ram/flash than some PC of 20 years ago, or can access external ram/flash natively
C++'s coroutine framework might be better then Rust's async in this case (Yes, C++ have it's slew of problems). C++ coroutine memory allocation is dependent on the awaiter type. Which is user provided. This allows space to inject custom allocators. Furthermore, deallocation and coroutine frame handling is also handled by the same awaiter. Maybe we can replicate that framework in Rust?
the video is great, but was the clickbait necessary? why not put more information in the title and thumbnail so we know what the video is about before entering it?
While I agree in theory with this comment, the reality is that most of us wouldn’t have clicked without the clicky title. I prefer more people learning about rust over my own problems with clickbait. Though chaning the title in the future seems pretty reasonable
@@erikwg3814 yeah, fair but some people, like me, are more likely to click on videos were they know what to expect from it and avoid clickbait stuff because it may be a waste of time
You either fade into obscurity longing for the day your videos get blessed by the algorithm so your channel can make a comeback or stay long enough to enjoy steady growth at the cost of reducing yourself to raw youtube flavored cringe.
I really like your explanation of GATs and why they're useful (particularly in async!), desugaring the async keyword and showing current workarounds makes it a lot more obvious why we needed them. Great stuff
Sounds like a superficial similarity and then also, I think it's nice to have some points of similarity for comparing and contrasting functionality, syntax, and semantics
1:51 im using async_trait in my embedded application (a basic command line OS) and it works fine without the standard library, but yeah the heap allocation part is necessary so you need to implement an allocator for it
I currently have an async function on &self. I want to spawn a bunch of threads and execute this function multiple times simultaneously (no mutability needed). However, as you said Future does not implement Send (I don't even care about the result of the function, but since futures are lazy I need to do &self.function().await. What would can I do about it?
If you can write the function you want to run in parallel as an iterator, you can use the rayon library to run iterations on every core at once. It's basically magic for parallization
@@lucky-segfault It's not really a function that I want to run in parallel. It's a function that I want to "duplicate" over multiple threads. You think I could still use rayon?
I don't get you what mean. Future is a trait just like Send. They are applied to types so a type impl Future can be Send or not. If you are using async in free function or plain impl of type the async is able to infer the type it produces and add Send bound to it.(Not always work due to some bug though). If you are using async in trait impl then you have to be explicit about the Send bound at return position. async-trait macro crate do this for you by default. It force you to produce Send types always. asnyc_fn_in_trait nightly feature does not offer a way to infer nor explicit express the Send bound(Hence it can't be stabled) and you need other nightly features like return_position_impl_trait_in_trait or GAT + type_alias_impl_trait to explicit adding Send trait to output type.
I would say "similar to F#/C#" rather than "similar to JavaScript", as async/await was firstly a construct of C#(actually it started in F# and was only later ported to C#)***, but very good video!
It's per design, they only want to gather emails. I never gave mine, who knows what they're doing with them. If you google it, you may find the cheat sheet. 😊
it's not complicated, it just delivers the features that should be there, unlike C++, which contains multiple implementations of the same thing in the name of """being stable"""TM
Introducing incomplete nightly feature to your audience is a very questionable move. And to people watching this video. Don't use it in any serious project unless you have the time to debug and report ICE. as well as be prepared for nightly breaking changes that can render your code not compilable.
@DownloadPizza AI era is coming. Almost 99% of programmers wouldn't be happy with lifetime annotations. Which language will ever force them to type such a tricky coding style in the future? My Pull request suggestion would be to provide two types of programming mode. 1) strict mode with lifetime annotations 2) easy mode without it and other toughest parts like borrowing, like JS/Typescript. any idea?
You need to deal with it, becouse the compiler can't. the compiler is always doing that for you for every single variable. Is in the handful times where it is ambiguous that it asks you for your input. And even then you can just give every variable the same lifetime, becouse that won't give you any issue 99% of the time. The reason the compiler won't do that for you, is becouse rust philosophy of not incurring hidden costs and the 1% of the time where things really really need to be dropped in a very specific way. But even being annoying. The advantages of the ownership overcomes the negatives 100 to 1
@@affegpus4195 Those toughest parts of Rust wouldn't be a ideal future aspect in the upcoming AI era. No One would be happy with such a strict coding style, except for core developers and hacky coding nerds. I'm not a core developer, but a full stack developer. I mean Rust foundation team should offer such an Easy mode in the future ! "strict mode: false" in the toml file. I don't think so my idea is nonsense, but more ideal for gaining the popularity.
@@maverick456-33 another copilot enthuziast :)) can you even code bro ? The rust compiler already embeds some way to manage like 90%-95% of the cases automatically, and the rest are not even that hard... Let Rust to the big boys and go play with your javascript toy.
📝Get your *FREE Rust cheat sheet* :
www.letsgetrusty.com/cheatsheet
Correction: The second limitation of this new nightly feature is that you can not spawn *from* a generic function while using a work stealing executor that requires spawned tasks to be Send. Note that the Rust team thinks this situation will be uncommon.
GAT -> async trait, the Rust team always has a super clear and steady path. I've never seen a team that ships software like this, especially in those "best FE framework" variety shows.
What about that "Yeet" nonsense they pulled ?
Look at his previous video
baremetal embedded programmer here: we avoid std lib BECAUSE of heap allocation.
Managing the heap is a pain, while having all in stack and static and without using recursive function, means we know ram and stack usage at compile time, and guarantee no leaks even on C/C++.
Very important for devices the MUST work, sometimes for years between reboot
I’ve never seen an embedded system running any standard libraries from the base release. Linus doesn’t write micro kernels
@@Stopinvadingmyhardware you can check the ESP32 chip environment in rust, it can be with or without std.
Oh, and Linux had branch to run stm32f4 and f7, that are the most common MCU at least between hobbist.
After all some model are dual code and have more ram/flash than some PC of 20 years ago, or can access external ram/flash natively
C++'s coroutine framework might be better then Rust's async in this case (Yes, C++ have it's slew of problems). C++ coroutine memory allocation is dependent on the awaiter type. Which is user provided. This allows space to inject custom allocators. Furthermore, deallocation and coroutine frame handling is also handled by the same awaiter. Maybe we can replicate that framework in Rust?
the video is great, but was the clickbait necessary? why not put more information in the title and thumbnail so we know what the video is about before entering it?
He's just playing by the algorithm's rules
🚬🗿
While I agree in theory with this comment, the reality is that most of us wouldn’t have clicked without the clicky title. I prefer more people learning about rust over my own problems with clickbait. Though chaning the title in the future seems pretty reasonable
@@erikwg3814 yeah, fair
but some people, like me, are more likely to click on videos were they know what to expect from it
and avoid clickbait stuff because it may be a waste of time
You either fade into obscurity longing for the day your videos get blessed by the algorithm so your channel can make a comeback or stay long enough to enjoy steady growth at the cost of reducing yourself to raw youtube flavored cringe.
@@jvcmarc sadly that will always be the minority, as annoying as it is clickbait is the youtube meta
Correction: the async-trait macro is fully compatible with no_std
Nice. I literally was frustrated that I couldn’t do this last night
I really like your explanation of GATs and why they're useful (particularly in async!), desugaring the async keyword and showing current workarounds makes it a lot more obvious why we needed them. Great stuff
That main difference is so huge that I would not really compare it to JS as it makes for quite a different developer experience.
Sounds like a superficial similarity and then also, I think it's nice to have some points of similarity for comparing and contrasting functionality, syntax, and semantics
"I don't know what you just said little kid. But you special man. You reached out...and you touched a brother's heart..."
1:51 im using async_trait in my embedded application (a basic command line OS) and it works fine without the standard library, but yeah the heap allocation part is necessary so you need to implement an allocator for it
FINALLY! I waited so long for that!!!
Can we have a tutorial about backend with DB and rest middle ware implementations please!
Yes, its called example folder on github
Check out 'brook builds' and his Axum playlist for this.
**Chadwick Boseman voice** We don't do that here.
can you dispatch dynamically now a trait that has an async function?
Holy shit, Fast Show reference 7 seconds in!
I wish trait containing async functions was object safe
I currently have an async function on &self.
I want to spawn a bunch of threads and execute this function multiple times simultaneously (no mutability needed).
However, as you said Future does not implement Send (I don't even care about the result of the function, but since futures are lazy I need to do &self.function().await.
What would can I do about it?
If you can write the function you want to run in parallel as an iterator, you can use the rayon library to run iterations on every core at once. It's basically magic for parallization
@@lucky-segfault It's not really a function that I want to run in parallel. It's a function that I want to "duplicate" over multiple threads. You think I could still use rayon?
I don't get you what mean. Future is a trait just like Send. They are applied to types so a type impl Future can be Send or not. If you are using async in free function or plain impl of type the async is able to infer the type it produces and add Send bound to it.(Not always work due to some bug though). If you are using async in trait impl then you have to be explicit about the Send bound at return position. async-trait macro crate do this for you by default. It force you to produce Send types always. asnyc_fn_in_trait nightly feature does not offer a way to infer nor explicit express the Send bound(Hence it can't be stabled) and you need other nightly features like return_position_impl_trait_in_trait or GAT + type_alias_impl_trait to explicit adding Send trait to output type.
@@realsong-fake Thanks, I don't know how but I fixed it and now it works
I would say "similar to F#/C#" rather than "similar to JavaScript", as async/await was firstly a construct of C#(actually it started in F# and was only later ported to C#)***, but very good video!
Actually it started in F#
@@benjinguyen9965
Oh, heavens, you're right. I had forgotten about the existence of F# for a moment, but indeed this is it.
@@diadetediotedio6918 The whole purpose of F# is testing stuff for C#. Or at least it seems like that.
Future is your average DMV worker
why is it always when i watch videos about programming i get confused before completely losing my understandment and my head feels dizzy?
danka
thanks 🤙
Your cheat sheet is not being delivered to my email... Can you look at that?
It's per design, they only want to gather emails. I never gave mine, who knows what they're doing with them. If you google it, you may find the cheat sheet. 😊
Rust is getting more and more complicated with each version lol
Yup. Eventually it'll be as much as a garbage can of features like C++
@@NathanHedglin I fear for the worst,
@@kasvith exactly, i feel like rust will end up incredibly bloated like c++
it's not complicated, it just delivers the features that should be there, unlike C++, which contains multiple implementations of the same thing in the name of """being stable"""TM
@@ac130kz like yeet!?
FINALLY
Introducing incomplete nightly feature to your audience is a very questionable move. And to people watching this video. Don't use it in any serious project unless you have the time to debug and report ICE. as well as be prepared for nightly breaking changes that can render your code not compilable.
That moment when someone uses the word "concrete" instead of "exact", but that's ok because you are a russian speaker too.
Concrete class is a standard terminology from OOP.
A concrete class is a class that has an implementation for all of its methods.
@@nxtktube Ohh ok thanks for clarifying
The animated background is very distracting!
One other major drawback of asynchronous coding in Rust is that you have to use Rust to do it.
„ haha x launguage bad”
rust is great it may not be perfect but its pretty easy to write
Diliked for the clickbait
I'm fed up with people desperately trying to please the algorithm
I don't like the unrelated clickbait title
Rust should get rid of lifetime annotation at least when coding; that is freaking annoying. Compiler should deal with it, not programmers.
@DownloadPizza AI era is coming. Almost 99% of programmers wouldn't be happy with lifetime annotations. Which language will ever force them to type such a tricky coding style in the future? My Pull request suggestion would be to provide two types of programming mode. 1) strict mode with lifetime annotations 2) easy mode without it and other toughest parts like borrowing, like JS/Typescript. any idea?
You need to deal with it, becouse the compiler can't.
the compiler is always doing that for you for every single variable. Is in the handful times where it is ambiguous that it asks you for your input.
And even then you can just give every variable the same lifetime, becouse that won't give you any issue 99% of the time.
The reason the compiler won't do that for you, is becouse rust philosophy of not incurring hidden costs and the 1% of the time where things really really need to be dropped in a very specific way.
But even being annoying. The advantages of the ownership overcomes the negatives 100 to 1
@@affegpus4195 Those toughest parts of Rust wouldn't be a ideal future aspect in the upcoming AI era. No One would be happy with such a strict coding style, except for core developers and hacky coding nerds. I'm not a core developer, but a full stack developer. I mean Rust foundation team should offer such an Easy mode in the future ! "strict mode: false" in the toml file. I don't think so my idea is nonsense, but more ideal for gaining the popularity.
@@maverick456-33 another copilot enthuziast :)) can you even code bro ? The rust compiler already embeds some way to manage like 90%-95% of the cases automatically, and the rest are not even that hard... Let Rust to the big boys and go play with your javascript toy.
@@maverick456-33 There is easy mode in Rust. It's called unsafe { }
wow we can finally murder javascript
Python was meant to replace it a decade ago.
42 seconds ago
First.