It's really inspiring to see how you guys stick to the values you have chosen for the language. How you push yourself to find a solution for zero cost abstraction async/await is just one example of that. Thank you Rust team!
I never programmed or read about async io and I understand what this guy talks. You guys are doing incredible good work and the result speaks for itself.
Amazing talk!! Very inspiring !! I chose Go over Rust 6 years ago cuz Rust didn't support async await natively at the time.Wish I had watched this video some time down the road. In 2024, i m starting with Rust.. Gotto to say its an amazing language for all people who consider coding as their passion.
That's the best explanation I ever had about asynchronous IO
5 ปีที่แล้ว +14
Awesome explanation! Rust always feels as this extremely well thought-out language regarding performance and such, which is a breeze looking at languages like JavaScript.
great & super video!! even the last 'x' ended the talk on a nice laugh. Boats is so good that even his mistakes are turned to a positive thing. super useful talk! loved it! I was floored to see a very important application of a the common proverb 'Good things come to those who wait.' Thanks Rust team for not destroying the language with futures and instead 'waiting' to make 'async' and 'wait' with the same quality that the rest of the language has! it was worth the 'wait' to not destroy Rust!
Actually Java did have Green Threads way way back in like 1.0 but they were removed a long long time ago and currently the only implementation of java.lang.Thread there is is one that maps to System Threads. But currently there is an effort called Project Loom in the Open JDK community that aims to introduce a second implementation called Virtual Threads which will be very lightweight Green Threads and which will hopefully make it into OpenJDK as a preview within a year.
Hi Rust community! I'm new to programming and low level computer knowledge. Computers are fascinating and Rust feels like a great place to start (also working through nand2tetris). I'm practicing recall. I'm wondering if folks could help me by telling me what I've got wrong, what's on the right track, and which of my take-aways from this talk are correct? This is what I have put together after watching: In Rust, async/await follows a model of sleep, wake on i/o, poll, repeat on a value of type `Future` where the future is a value waiting to be resolved in a pre allocated heap of memory called a "state machine." * The statemachine is heap memory that is "pinned" in place because it contains references to itself. * In Rust, memory that is "pinned" cannot be moved or copied until it is dereferenced. * Were the statemachine to be moved or copied the self-references would point to the wrong block of memory. * the statemachine tells the compiler how much memory is needed for each state the future will be in over the course of it's life. The compiler takes the sum of this memory and now knows how much it will need to look for on the heap at runtime for a given future. from what i understand, * an "executor" and a "waker" pass a reference to the statemachine back and forth. * The executor uses the value stored in the statemachine until it puts it to sleep because it is waiting on i/o. Then, the executor passes the reference to the statemachine to the "waker." The waker will wait until it is notified from the operating system that i/o has occured (at this time, the value in the statemachine is of the same state it was when the executor passed the reference). Now the waker passes the reference back to the executor so it can manipulate the value in the statemachine until it reaches the next state. This repeats until the value in the statemachine hunk of memory reaches it's final state. At that point the value in the statemachine will no longer change that the hunk of memory that stores the statemachine will remain "pinned" until it is dereferenced. BTW, even if my understanding is correct, is async/await still implemented like this? Thank you!! Keep being great and have a good day!
Thats what rust futures already do. You join asynchronous operations using .and_then() which is similar to >> or bind in haskell. async/await in rust is simply syntactic sugar around those combinators that also lets you use them on expression blocks. Similar to what the "do" keyword is in haskell as well.
![[TH] 2024 PMGC League | Survival Stage วันที่ 1 | PUBG MOBILE Global Championship](http://i.ytimg.com/vi/FVFT-PFwU80/mqdefault.jpg)
It's really inspiring to see how you guys stick to the values you have chosen for the language. How you push yourself to find a solution for zero cost abstraction async/await is just one example of that. Thank you Rust team!
I agree, I'm watching this now and I'm inspired
I never programmed or read about async io and I understand what this guy talks.
You guys are doing incredible good work and the result speaks for itself.
Best syntax ever. Simple, beautiful and so readable. Thank you!
Here I am, 5 years later, and I can't imagine writing async Rust code without async/await. Very well done!
Without Boats? Instant like
Amazing talk!! Very inspiring !! I chose Go over Rust 6 years ago cuz Rust didn't support async await natively at the time.Wish I had watched this video some time down the road. In 2024, i m starting with Rust.. Gotto to say its an amazing language for all people who consider coding as their passion.
This was an excellent talk. Thanks for sharing! I especially loved the "in-room" feeling of the video - felt a lot like a TED Talk. Thanks again!
Pretty neat. This project is trying to work out where they want to be, rather than focusing on getting somewhere fast.
That's the best explanation I ever had about asynchronous IO
Awesome explanation! Rust always feels as this extremely well thought-out language regarding performance and such, which is a breeze looking at languages like JavaScript.
Excellent work from the Rust team. Boats killed the Async talk. Rust is a beast guys : )
this video is a good reminder of how as a software engineer i am riding on the shoulders of giants.
Really reminds me of the dart future API. Of course that makes sense since it's just async await.
Thanks for putting this talk up!
great & super video!! even the last 'x' ended the talk on a nice laugh. Boats is so good that even his mistakes are turned to a positive thing. super useful talk! loved it!
I was floored to see a very important application of a the common proverb 'Good things come to those who wait.' Thanks Rust team for not destroying the language with futures and instead 'waiting' to make 'async' and 'wait' with the same quality that the rest of the language has! it was worth the 'wait' to not destroy Rust!
Excited, hope it's just as nice as in JS
Man great video, though I think you should have taken a Bensedin or something for the nerves :D
I'm curious to know how much CPU overhead the polling adds, and how does this compare to something like Node.JS? Anyone know?
The code on the slides is hard to read
I love this kind of stuff
what is the slides presentation style you use? looks very cool, like old projectors in which you should insert cards with pictures on it
Here for the monthly viewing
"Zero cost" is like 1 allocation. Callback model does not work in rust because it requires allocation to keep callback.
i wonder if the “zero-cost” constraint to the language design will cause the language low level api surface to eventually become very large
I think this was mentioned by Alex Chrichton "RustFest Zürich 2017 - Tokio: How we hit 88mph by Alex Crichton" at around 19:30 forward
Java has native system threads as well. It has abstractions over green threads - sure, but it's not default
Actually Java did have Green Threads way way back in like 1.0 but they were removed a long long time ago and currently the only implementation of java.lang.Thread there is is one that maps to System Threads. But currently there is an effort called Project Loom in the Open JDK community that aims to introduce a second implementation called Virtual Threads which will be very lightweight Green Threads and which will hopefully make it into OpenJDK as a preview within a year.
Hi Rust community! I'm new to programming and low level computer knowledge. Computers are fascinating and Rust feels like a great place to start (also working through nand2tetris).
I'm practicing recall. I'm wondering if folks could help me by telling me what I've got wrong, what's on the right track, and which of my take-aways from this talk are correct? This is what I have put together after watching:
In Rust, async/await follows a model of sleep, wake on i/o, poll, repeat on a value of type `Future` where the future is a value waiting to be resolved in a pre allocated heap of memory called a "state machine."
* The statemachine is heap memory that is "pinned" in place because it contains references to itself.
* In Rust, memory that is "pinned" cannot be moved or copied until it is dereferenced.
* Were the statemachine to be moved or copied the self-references would point to the wrong block of memory.
* the statemachine tells the compiler how much memory is needed for each state the future will be in over the course of it's life. The compiler takes the sum of this memory and now knows how much it will need to look for on the heap at runtime for a given future.
from what i understand,
* an "executor" and a "waker" pass a reference to the statemachine back and forth. * The executor uses the value stored in the statemachine until it puts it to sleep because it is waiting on i/o. Then, the executor passes the reference to the statemachine to the "waker." The waker will wait until it is notified from the operating system that i/o has occured (at this time, the value in the statemachine is of the same state it was when the executor passed the reference). Now the waker passes the reference back to the executor so it can manipulate the value in the statemachine until it reaches the next state. This repeats until the value in the statemachine hunk of memory reaches it's final state. At that point the value in the statemachine will no longer change that the hunk of memory that stores the statemachine will remain "pinned" until it is dereferenced.
BTW, even if my understanding is correct, is async/await still implemented like this?
Thank you!! Keep being great and have a good day!
Great
That was a great explanation, thanks for this!
"Zero-Cost Async IO" for very specific definitions of "cost"...
Why create keywords when you can create a library using concept of monads like Haskell?
Thats what rust futures already do. You join asynchronous operations using .and_then() which is similar to >> or bind in haskell. async/await in rust is simply syntactic sugar around those combinators that also lets you use them on expression blocks. Similar to what the "do" keyword is in haskell as well.