The What and How of Futures and async/await in Rust 

I hope you still liked it after watching ^_^

@@jonhoo I always finds something to learn from your videos ever since I watched async-ssh. Keep going and thanks for the quality content !!

​@@jonhoo Great Content, thanks for doing this!

Same here.

That's a cool idea! I'll look into adding it to jon.thesquareplanet.com/live-coding/ soon!

Yes! Despite this video's age, it is still the best overview of Rust async I have seen. It would be *great* to get an update. Much has happened in the past 2 years!

I cannot it.await

+1 an update would be great!

There is a newer video about this here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ThjvMReOXYM.html

in rust, things that are trivial in other languages require a phd and 2 years of your life

@@dntwantgglplus, I have not found this to be true personally. I feel that C and C++ are more difficult languages. I do feel like lifetimes should be more automatic though, allowing function parameters to take ownership and function returns to give that ownership right back. I don't know how to survive without structs right now, and that seems unnecessary.

​@@dntwantgglplusthis is only true in the case where other languages have obscured tasks which require education to understand

26:09 XD

that's psychedelic AF XD but super interesting as ever !

I think it's for a couple of reasons. First, having a move constructor gets pretty complicated, because now the compiler has to inject calls to that constructor whenever a value is moved, which can potentially be in a lot of places, most of which are pretty irrelevant. The other answer is that having a move constructor probably leads to _more_ complex interactions, not less. The current Pin solution, while tricky to wrap your head around, is highly tailored to what it has to do, and does not introduce _lots_ of additional behaviors that the compiler needs to reason about, nor does it really change the language at all (remember that Pin was initially just a library!). The original RFC also has some discussion you may find interesting: rust-lang.github.io/rfcs/2349-pin.html#comparison-to-move

@@jonhoo Right on. Yeah Pin is great, there are definitely use cases where one needs to explicitly require no moves or they simply aren't necessary, futures for example. In c++ this is usually done by deleting the move/copy constructors respectively. Afaik, Rust already has a default move constructor, probably just memcpy +. Anyways, customizing the move "constructor" or function solves the issue of having to reset self references. It doesn't need to be a "constructor" it could be a trait, if there isn't one already (like Copy?, lots to learn), and an annotation on a member that references another member in the same struct could be used to automatically derive the proper move procedure as far as self referencing structs are concerned. Regarding specialization, I think overloaded functions could also be very useful in there, which is basically what overloaded functions are for. Granted, some other more explicit means/syntax for the user to specify specialized functions could alleviate the compiler of complicated overload resolution especially with regards to generic types (I'm thinking of C++ template specialization and how that affects overload resolution there). Anyways, I think Rust is a great a language and I'm excited to see how it evolves. Thanks again for your great streams! They've taken miles farther in learning Rust than any other source :)

Glad to hear it! I mean, you do have limited overloading by virtue of the various traits that different operators use, like Add for +, AddAssign for +=, etc. But you may be thinking of use-cases that are not met by just implementing those traits?

@@jonhoo Well function overloading and having decent overload resolution with generics would essentially solve the specialization issue that they are working on in nightly. That's at least how template specialization works in C++, you define a generic function, and then a specialized version for whatever types you need to treat differently, and then the overload resolution takes care of calling the appropriate implementation at compile time for whatever types you're using at the callsite. Anyways, it's not a major issue at all, the main reason I chose to learn rust and start a project with it over C++, isn't because of the static analysis built into the compiler (though that is certainly a nice feature), it was Cargo and the couple years of maturity that async/await Rust has over C++. This thread highlights pretty well what I think I'm trying to say: internals.rust-lang.org/t/idea-limited-custom-move-semantics-through-explicitly-specified-relocations/6704/16 The choice to not implement certain features because they would be "too complex for people and they would abuse them and the world would end" rubs me the wrong way and am pretty sure such arguments are a sort of fallacy that distract from why some features are actually useful. I'm used the footgun of C++, and the power that it gives me as a developer. There's this sort of movement, not related to Rust directly, trying to push software development/programming onto the masses ("Everyone should code"), which I disagree with. Programming is an engineering discipline, it's not flipping burgers, and I think Rust sometimes treats us like McDonalds employees. The "safety" of Rust is one thing I like (read built-in static analysis and philosophy), but on the other-hand, in certain cases it does become an issue. One thing that concerns me about any community is how dogmatic it is. For example, when learning to code in a functional style for X imperative language, one shouldn't be too dogmatic about being functional as it can lead to poor performance or totally unreadable code. I think in Rust the issue, "we're not going to implement that feature for XYZ reasons due to our philosophy" which ends up leading to other feature being much more difficult to solve, or essentially just reinventing the wheel with a different syntax and name. That's all. That said, I still really like Rust in general, it has a really nice blend of imperative and functional style, it's like if C and Haskell had a baby and ... ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-tTf-nHFnntE.html

Thanks! I'm using MyPaint on Linux with a Huion Inspiron 640P. I think pretty much any tablet will do for this sort of sketching though.

Glad you found it helpful! I'm not entirely sure I understand your question; it's not a problem to executee a future on a different worker, all that matters when work stealing is that the notifications are still issued from the original worker. To avoid cross-thread communication, we may therefore want to return a NotReady future to the queue of its origin worker.

@@jonhoo thanks for the reply, I'll try to clarify. Why can't you just keep it on the stealing thread as is? It's been stolen in a ready state, so it has nothing it's waiting for? So if it does become unready can't it just notify the waker on the new thread. I'm sure there is a reason, but I can't quite catch it.

Ah, you _can_ keep it on the same thread, but having one thread notify another thread is much more expensive than notifying yourself. If we keep a stolen future on the other worker, then we'll have to keep doing cross-thread notifications, whereas if we return it we no longer have to!

Well, kind of. But the analogy isn't perfect (beyond the fact that the languages are quite different). One of the biggest differences is that with tokio you get multithreaded execution, which Node.js doesn't generally give you :)

Many thanks for your response, bro!! 👏👏👏 So all we need now an equivalent for Express.js and to be able to use React.js 🤩🤲

These days, tokio has a single "floating" reactor that whichever worker thread is idle is responsible for turning. It can move from one thread to another as load changes. I believe there are plans to allow multiple reactors, but to my knowledge it has not been implemented (or been needed) so far.

I'm actually not entirely sure how the real `await!` interacts with dropping local variables. My guess would be that they're dropped according to normal scoping rules, though I'm not sure how the compiler enforces that. Keep in mind that the `enum` I give isn't _actually_ what the compiler uses, it's just a handy way to think about it :)

I said this around 2:14:44, and you're totally right, tokio-codec is not going away. I somehow got it in my head that it was not going to be included with tokio, but that's not the case. tokio-codec is alive and well :p

I think implementing an atomic operations (fetch_add, fetch_sub) might work, imagine the task was_notifed state is not bool instead is an integer, where the threads(b,c) do fetch_add while thread_a do fetch_sub. so the executor will just check the was_notifed integer state, you think this kind of operation is inexpensive?

I'm not entirely sure what the question is? Are you concerned about correctness or performance here? Wakeups are already implemented using atomics :)

hey @@jonhoo, am concerned more about the correctness first and then the performance as well, after giving it a lot of thoughts, I guess having a notification channel is might be better than fetch_add,fetch_sub, because the channel will only consume O(n) where n is the tasks that are ready to do progress(have notification), while managing an atomic integer state will force executor to loop through all executor_map(which hold all the tasks) and then check if it was_notified flag(have integer atomic state greater than 0), what do you think? am new to the rust world, and without you I might never understood the overall picture, so all the credits to you, as am currently implementing(actually still designing) a shared nothing architecture I hope if you could advice whether is good to go with epoll or io_submit/io_getevents(batching), or mostly io_uring(am still wondering how to do that in futures world) and maybe emulating epoll with IORING_OP_POLL_ADD/REMOVE, don't you think this might be better than blocking on epoll?

sorry back again to the question, "Wakeups are already implemented using atomics", consider the task is an actor, this actor receive events from its channel, therefore it should only be awaken once per event, and thats why I went with shared nothing architecture model, otherwise I might go with work stealing pool if I can ensure that no two/x threads will awake the actor at the same time! :) Thank you again for your quick response, please take the time.

Ah, sorry, to be clear, what I present in the video is an _extremely_ simplified view of what the tokio runtime actually does to schedule tasks and wakeups. In practice, a _lot_ of optimization and testing has gone into making it both correct and very fast, and that includes several fancy lock-free datastructures, clever use of atomics and thread-locals, as well as lots of algorithmic work on scheduling and such. The current tokio runtime actually looks a lot like the runtime that Go uses for its goroutines. If you want to know more about how the runtime _actually_ works, I would recommend you head over to gitter.im/tokio-rs/tokio where the tokio developers hang out, or just dive into the code yourself! They (Carl in particular) can probably also give you better answers than I can about what kind of syscall interface would work best for your intended use-case.

I stream on both. My Twitch channel is www.twitch.tv/jonhoo.

@@jonhoo awesome thank you!

Oh, that's just the default Firefox Developer edition theme. I think there are ways to enable the dark theme on non-Developer editions too with some fiddling with the settings if you Google it!

@@jonhoo What about putting the url bar/etc at the bottom?

Hmm, that's an interesting idea. What makes you think that'd be useful? Most of the relevant text is visible in vim anyway?

Yes, most of the text os visible, but not your keybindings. Would be cool to see what shortcuts you are pressing.

True, but I think that'd lose novelty value very quickly, as I'm not using anything _super_ fancy most of the time. The code is the focus, not the editor. I might do it for a shorter stream though, that's a good idea!

Ty for your attention Jon :)

I'm not sure I follow the question - a type only gets an auto trait if all of its members implement the auto trait. If any member does not, the parent type also does not.

@@jonhoo That was my understanding. Therefore, because `Bar` included `Foo` as a member, and we specifically opted out of `Unpin` on `Foo`, that should mean that `Bar` is also `!Unpin`, and thus not allowed to be moved.

Yup, that is correct. When you then use `Box::pin` (which gives you a `Pin`), it prevents you from moving the `Bar`. However, you _are_ allowed and able to move the `Foo` _inside_ `Bar`, since the `Foo` is _not_ behind a `Pin`. Or, in other words, the `Pin` only applies one "level" deep.

@@jonhoo Oooh, that was the missing link! Thanks! Amazing video, btw! I'm always interested in learning the internals of stuff like this.

Nope, just the USB microphone, so not entirely sure what happened there. Hasn't happened since either :shrug:

Oh, that's not base16. That's just the docs.rs dark theme. Click the little gear near the top left and choose "dark".

This is Arch Linux. See also my walk through of my setup here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ycMiMDHopNc.html

Hi Gang! I go through all of that in this video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ycMiMDHopNc.html

Yup, all of this still applies to futures being in the standard library! The design of futures themselves hasn't really changed.

@@jonhoo Thanks. This video really is unbeatable!

You should search for "Neal Wu" dude literally does 156wpm while typing code.

Should be fixed now!

It's xmonad actually, but any tiling window manager works just as well! I have a shortcut in vim for switching quickly back and forth between the two most recently-used buffers. See github.com/jonhoo/configs/blob/b6d4aee616d234f581766b467a0e772e775cc53f/editor/.config/nvim/init.vim#L372. In stock vim you can do so using C-^.

The source code of what?

The exact syntax isn't terribly important I think -- this video is more trying to teach you how futures and async/await works under the hood, and then showing that it does in fact return a Future is more important (I'd argue) than being technically correct to the syntax. As for the order of async and fn, I don't think that's terribly important when it comes to conveying understanding of the underlying concepts, but you're totally right! That is something the compiler would tell you pretty quickly if you started writing async code though :)

@@jonhoo That's a fair point, yeah! Rereading my original content, I'm sorry if I came across too dismissive. It's currently 6AM, and I haven't gone to sleep yet. I do think you did a good job of getting the main point across, and in fact, I would like to at least thank you for the excellent stream. I am just a little worried that it could be a little confusing to show _impl Trait_ being mixed with the _async_ function signature like that when _async_ itself is implemented in terms of _impl Trait._ But you're right, it's not that big of a deal. Still love the video!

Hehe, no worries, comments online are notoriously bad at conveying tone and context, so I just assumed you were coming from a good place :) I'm glad you enjoyed it and found it helpful! You are totally right that it's not technically accurate, and I agree that's unfortunate, but at the same time: a) an async function really does return something akin to impl Future, that's just not what you _type_, so for the purposes of exposition, that's probably a better way to show what's going on "under the hood"; b) if someone were to try to write async fn -> impl Future, the compiler would correct them very quickly, and they would realize that the extra impl Future bit isn't necessary; c) the return type of async fn actually _was_ written impl Future for a while, and then it was changed to avoid the extra boilerplate; and finally d) I can't actually change the video at this point, so sadly I don't have a good way to resolve this after the fact. I suppose I could mention it in the video description, but I suspect very few people actually read that anyway :p

That's interesting, you're right, it does seem pretty quiet, but I'm not sure why. I think my microphone is turned all the way up, but something is clearly wrong. I'll make sure to look into it for the next stream!

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-KPbrI3xWdCg.html :)