Rust's Journey to Async/Await
Vložit
- čas přidán 10. 11. 2019
- InfoQ Dev Summit Boston, a two-day conference of actionable advice from senior software developers hosted by InfoQ, will take place on June 24-25, 2024 Boston, Massachusetts.
Deep-dive into 20+ talks from senior software developers over 2 days with parallel breakout sessions. Clarify your immediate dev priorities and get practical advice to make development decisions easier and less risky.
Register now: bit.ly/47tNEWv
--------------------------------------------------------------------------------------------------------------------------------------
Video with transcript included: bit.ly/2XcjHbj
Steve Klabnik gives an overview of Rust’s history, diving into the technical details of how the design has changed, and talks about the difficulties of adding a major new feature to a programming language.
This presentation was recorded at QCon New York 2019: bit.ly/2KFk7SO
The next QCon is QCon London 2020 - March 2-4, 2020: bit.ly/2VfRldq
For more awesome presentations on innovator and early adopter topics check InfoQ’s selection of talks from conferences worldwide bit.ly/2tm9loz
#Rust #Async #ProgrammingLanguage - Věda a technologie
The amount of information he kept in his head during this presentation... the flawless delivery... so coherent and easy to understand... great programmer! 😲
this is basically a repeat of operating systems class without the creating an operating system and doing scheduling components
It's a lot easier to keep track of the words & definitions if you understand the fundamental key concepts
He just understands the concepts, It's easy to talk about things you understand. Presentations like people do them in school all the time, imo, is time efficient maybe but this is quality because he knows what he is talking about.
@@Seomon1 Sure, but there are also a lot of people with knowledge that aren't that great of teachers.
Tbh The Rust book is the best programming books I've encountered.. Not just "do this, this is the way" but it also covers why Rust does this; how does it work in the underlying operating system etc. So basically a CS class baked into the book itself and the whole book is a ELI5 kind of thing.
Steve is a gift to the community!!
We're lucky to have Steve in the Rust community. Such a great ambassador
yupe, the guy talks with so much enthusiastic and excitement. it's so fun to watch.
"1.38. For sure."
_lands in 1.39_
à
After watching/listening this talk, I appreciate even more the work of all those involved people have done to create programming languages.
Really great talk. I highly appreciated how Steve was able to independently speak of so many topics, which chronologically tied to the story of how Rust got async await.
Aside: I had been wanting to revisit topics like native vs green thread, sync/async blocking and non-blocking, io models and a lot of the topics he addressed on a per individual slide basis
I'm so happy the rust folks went that way. There's also another aspect to the green vs native dilemma, which is system instrumentation tools (dtrace, linux uprobes, systemtap, ...). Often when you're doing some non-trivial instrumentation you're interested in pairing two events (e.g. entry into function A and entry into function B) based on the thread they happened on, and you can't do this with green threads because the OS thread is just a "carrier" for green threads.
The `.await` syntax is actually pretty reasonable, I don't understand why no one has used it before in other languages. Chaining async code is often very awkward in javascript, because you need wrap await calls in parenthesis and order of operations switches from left to right side of expression and vice versa, often multiple times. And it's not like a minor issue that was not obvious from the start, it's something you hit after five minutes into async and deal with it every time you use it.
.net (f#, c#) had that since a long time ago. The more primitive ideas have existed in GUI programming fir ages. None of this has been invented by the Javascript community as implied here. Most are recycled ideas with extra "syntax sugar".
@@defendliberty1289 I didn't imply it was invented by javascript community and it wasn't even my point.
First when I saw that `.await` syntax, I was so disappointed. But then, on a later slide, when he showed that chained await example, I just realised this is so brilliant!! Why haven't people used this elsewhere? Chaining of awaited values is a hell in js with parenthesis all around. Doing it this way is sooo fluid to write! I already love this `.await` without ever having written a single line of async rust yet! 😆
to be fair though, if you want .await in JS, why no just use Promises?
@@deformercr6680 Good point and I actually do that. I definitely use Promises directly more often than async/await syntax
Correction. F# conceived of Async/Await first implemented with Computation Expressions. Computation Expressions are a general form of Async/Await which can make monadic code appear to be imperative programming style. C# first implemented Async/Await without computation expressions but later made them computation expressions but that made the Async/Await kind of awkward since it isn't always doing concurrent programming. Typically if someone in C# is using a computation expression outside of Async/Await they use the "from/in" style.
See docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions
Nobody cares about Microsoft languages
@@Adam-cn5ib I love you too. You're a wonderful person with a strong and beautiful spirit.
If you have the time to watch the video I highly recommend it. It was a great presentation!
That's just making async code look synchronous. It doesn't use the glorious terminology "async" and "await". :D
@@Adam-cn5ib I know you are a nobody! :)
Such a great talk! It really exemplifies how Rust's approach to mature slowly, has allowed it to snowball fantastic world-class features by building upon also fantastic world-class features. Now anyone can empower themselves with highly correct, performant, and maintainable code. How would you get the wrinkles out of your home-rolled solution that will cause mysterious bugs in production on your own when it takes an whole community and researchers drawing on years of experience just to get something actually right. When you think about it, most of our programming languages were not design openly. The foundations were already laid before open contributions started flowing in. Or capricious standards bodies fossilized languages long before they should have been. In the end the Rust community really is it's killer feature.
Wow. Few programming talks are so entertaining, informative, and inspiring! 🦀 ❤️
Great talk
Fantastic presentationen. Entertaining and packed with lots of knowledge.
Always a pleasure to listen to Steve. Very entertaining! I'm happy that Rust was able to learn from other languages, managed to get through all those problems and eventually reached its current state. Goes to show what a healthy and open community can do.
Timeless presentation, thank you.
I think that rust doc bug still exists today. Such a good talk
Amazing presentation!
Wow, a green threads presentation without java, lol. Thanks, appreciate the history and information. Trying to use Rust to recreate Celery and even build a broker. Hoping to stick with Rust over Go. used to program a lot of Scala so the language feels similar with the exception of ownership and syntax of course ;)
Great talk. Wow. Thank you. Learned so much from this.
Nice! very informative.
super comprehensive talk!
awesome talk.
Thanks! Cool talk!!!
Awesome presentation! Many thanks Steve.
Well explained. Thank you.
14:46
"If you see this module it says the same thing two times. I don't know."
Thank you!
The definition block is helpful with understanding the big picture. That's what separates a good presenter from a bad professor.
Very good talk.
great presentation
15:44 vs 17:38
Nice presentation. Talk about juggling a bazillion considerations amidst tip-toing through a minefield...!
I don't want to use Rust anymore, because of async. I tried to avoid it, but it seems to become more and more common with crates. Why can't I just disable it, or tell the program that it should just block like on normal functions, or do something like .not_await
Apache's prefork MPM is so-called because it forks before connections arrive, relying on accept() to distribute among the processes. Not concurrent, but not fork-per-connection, as each process returns to handling connections. The distribution of connections is thus also parallel.
Also, it is still used because there are several modules that are not thread-safe and hence cannot run under the other models (e.g.: mod_php)
Impressive talk.
I'm confused by the definition of concurrency in the introduction. @3:21, the slide actually seems to be talking about time-slicing, not concurrency. Concurrent = "running with", from the Latin, ie multiple tasks "running with" one another. MIT agrees : web.mit.edu/6.005/www/fa14/classes/17-concurrency/. Am I missing something ?
In simple terms:
Parallel = run at the same time with own resources
Concurrent = compete for resources
Asynchronous = use of the resources effectively.
The concurrent example demonstrates two tasks competing for CPU time.
A parallel code will run in parallel until they start to compete for resources(e.g: CPU Time, Memory). When there are more tasks than the amount of resources to serve these tasks, they start compete for these resources and run concurrently even though they started in parallel. This is the main reason async is required, to make good use of these resources.
3:12
Not entirely true although that hardly matters with regards to this talk.
You can get instruction level parallelism.
Especially if you do out of order execution.
This means that you have a single core with specialized execution resources for various different tasks (more than just a touring complete core in other words) where all the resources are available for the core, but every individual step of a program doesn't necessarily require every resource in the core, so you allow the core to start other tasks before the previous ones are done.
It could be different pipeline stages, so getting data from memory and figuring out what exactly the instruction is could be one task, then actually making a calculation is one and the next instructions data can be fetched and prepared while the first one is going through the actual math/logic then finishing up the task could be a last stage.
If you also have out of order execution rather than just a superscalar one you could also have a instruction queue and look at it to see if any of the instructions in it can be executed simultaneously.
Say if you both have two fixed numbers that have to be added together but also a logical evaluation like if this number is bigger then that number return true or whatever and a third instruction say multiplying two floating point numbers the those three could potentially be done at the same time if they don't have any dependencies like any numbers required for those instructions potentially being changed by earlier instructions, that way you can have one queue where you both have the instructions that's about to be executed in a queue and you can have the finished results of them stored in a queue too and the processor will only do whatever it needs to do with the finished result when all the previous instructions have been executed and that final one is placed in the right order.
But its actual *execution* doesn't have to be done in order, one by one.
So that way you can get the code executed faster and it won't matter as much that you have more specialized resources then what each individual instruction can use since the out of order execution ensures that the resources are actually used.
You can also have multiple threads with limited extra resources allowing the second thread to make use of whatever resources the first one doesn't use etc.
Good to hear about the c10k doc this century! I was mentioned as a contributor in the original version but it appears Dan deleted my part :( Good times.
Isn't select() blocking asynchronos io in a way since it's blocking but it can react to multiple different events?
Yes, its blocking but not async unless you use it to invoke a custom callback supplied by the user.
I dropped my last project in Rust because I was spoiled from using async/await in Python. Rust is definitely back on the menu.
Futures and Promises are great .... but having tried to decipher a python Twisted stacktrace more than once, I approach them with caution :)
Maybe the system kernel itself should be changed to the green threads?
Frio Hao, totally. Async/await not general purpose lang feature. Just CS community madness! But it will be fixed
I think someone needs to create some sample codes ASAP, because there are no examples in the internet about async/await. I still don't know how to use them.
Steve looks like 24 and 37 at the same time
Nobody ever seems to explain why Green Threads are "Green".
"Green threads is slower when calling C code"? For what?
calling C code, duh
Probably is related to context switching between a green thread and an actual thread that will probably require some synchronization
@@guibirow no, he even explained it. it has to do with the fact that green threads don't use a C-compatible stack, therefore when you do an extern call to C you have to first set up a fake stack that the C ABI expects
if golang is synchronous/non-blocking why the `go` keyword ?
I find the blocking/non-blocking explanation a bit non-intuitive. Blocking is usually used in terms of GUI where its clear that application is blocked/frozen. In backend world it means that you've basically put the thread to sleep and are wasting resources but you have not blocked anything from outside point of view. I wonder if there is a better expression?
Edit: still a great talk
Hi ! I used to do a bit of GUI programming a while back and I have a feeling that I might see where you're coming from. However, since intuition is quite personal (and elusive), I don't know how best to help. I thought I'd write some things that you might know even better than I do in a way that feels intuitive to me in the hope that it helps you build your own intuitive explanation.
The problem with blocking in GUIs comes up in single threaded GUI frameworks (which most of them are; especially on mobile). It usually refers to blocking the GUI thread which handles most of the I/O (user input and graphical output), which is bad because then the screen does not get updated and the user cannot interact with the app and the world explodes. On the backend, the I/O is usually some network or socket read/write operation and, by contrast to GUI operations, any OS thread can handle them. So even if one thread is *blocked* waiting on some response from a database while a web client tries to connect, it is reasonable to believe that there is another thread available that is not blocked and which can begin serving that client. And if there isn't we just spin up a new thread and keep the client happy. As you said, up to now, nothing looks blocked from the outside point of view. The problem starts when the server has to deal with a high frequency of client requests (think in the order of 10,000 requests per second). In that case, when a client request comes in, there may already be 10,000 threads already blocked serving other clients and the program may not be able to spin another thread because it would run out of memory. The client request would need to be rejected and this is where the "blocking" gets to be see from the outside point of view: the browser "hangs", the user cannot browse the website and the world explodes. The "blocking" on the backend would manifest as the inability to serve client requests, which, if I think about it, is not that different from the definition of "blocking" in the frontend :)
Sorry for the verbose answer and for only saying things you most likely already knew. If this helped or offered some kind of perspective, I'd love to hear the intuitive explanation you arrived at on this topic. Cheers!
mark
语速真快呀
I still favor the golang model.
Which is find until the golang garbage collector comes and bites you.
same here. at least rust lets you choose your poison. hopefully the rust world will never see something like node's colored function fiasco.
boring , someone ignoring supercomputer rebranding part of working stuff into a new stuff
Blocking/Async allow to check the data coming but are not processed until all check are done. Instead of blocing , check and then process
The Rust async ecosystem is a mess of incompatible forced runtimes. You no longer pick a library because it's good, you pick it because it supports your currently used runtime. And if there's no library for your runtime, you're f***ed. Crates even specify their runtime in their name, such as "tokio_tungstenite". This is ridiculous. I've never seen a more broken, badly thought out async/await implementation.
Detail video in Hindi
Popcorn make with butter
Promises, futures were in the literature long before the millennial giving the presentation could do his alphabet lessons.
He's wrong about concurrency. You can do multiple things at the same time even on a single core CPU, e.g. using the processor, and writing to stdout is possible, in parallel using a concurrent approach (such as what go has)
Rust being created by Mozilla makes me skeptical of it. Firefox has HORRID performance, and this has been a problem for YEARS now. To be perfectly clear: Chromium runs just fine on my 1.20 GHz laptop. Firefox did NOT. (even on Linux) What makes them think they will be able to create the ultimate programming language when they weren't even able to fix their flagship product? Sorry for the cynicism but I think we're all fucking tired of snake oil salesmen out there.
43:50 yea that syntax definitely looks weird. You would be expecting .await()? instead, but this way, in emphatises that it is not a function, so I think it works fine. Also BIG PLUS that you can put it at the end, it really makes long chains better:
a.b().await?.c().d().await()?.e
is much better than
(await(await (a.b())?.c().d())?.e
Awesome presentation!