The amount of information he kept in his head during this presentation... the flawless delivery... so coherent and easy to understand... great programmer! 😲

We're lucky to have Steve in the Rust community. Such a great ambassador

"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

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.

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.

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.

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! 🦀 ❤️

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.

Great talk

Fantastic presentationen. Entertaining and packed with lots of knowledge.

I think that rust doc bug still exists today. Such a good talk

Timeless presentation, thank you.

awesome talk.

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 ;)

Amazing presentation!

<a href="#" class="seekto" data-time="944">15:44</a> vs <a href="#" class="seekto" data-time="1058">17:38</a>

Great talk. Wow. Thank you. Learned so much from this.

The definition block is helpful with understanding the big picture. That's what separates a good presenter from a bad professor.

super comprehensive talk!

Nice! very informative.

Thanks! Cool talk!!!

Well explained. Thank you.

Thank you!

<a href="#" class="seekto" data-time="886">14:46</a> "If you see this module it says the same thing two times. I don't know."

Awesome presentation! Many thanks Steve.

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

Very good talk.

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.

Impressive talk.

great presentation

Nice presentation. Talk about juggling a bazillion considerations amidst tip-toing through a minefield...!

I dropped my last project in Rust because I was spoiled from using async/await in Python. Rust is definitely back on the menu.

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.

I'm confused by the definition of concurrency in the introduction. @<a href="#" class="seekto" data-time="201">3:21</a>, 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 ?

<a href="#" class="seekto" data-time="192">3:12</a> 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.

Futures and Promises are great .... but having tried to decipher a python Twisted stacktrace more than once, I approach them with caution :)

Isn't select() blocking asynchronos io in a way since it's blocking but it can react to multiple different events?

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.

Maybe the system kernel itself should be changed to the green threads?

Nobody ever seems to explain why Green Threads are "Green".

Steve looks like 24 and 37 at the same time

if golang is synchronous/non-blocking why the `go` keyword ?

"Green threads is slower when calling C code"? For what?

mark

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

语速真快呀

I still favor the golang model.

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.

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

Promises, futures were in the literature long before the millennial giving the presentation could do his alphabet lessons.

Detail video in Hindi

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.

<a href="#" class="seekto" data-time="2630">43:50</a> 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!