I've seen a number of people struggling with writing async code over the past year or so. This talk was a really great walk through of the history of async I/O in Rust leading up to the current state of things. Thank you!
I've been obsessed with concurrency since I was 10. I think it's fun and relatively easy if designed correctly. If you limit how a object can get in a certain state to a small bit of code, instead of strewn all over the system, any time there is an issue with that state, you only have to look at a little bit of code. Sometimes it is desirable to lose data in order to gain scalability. Will Rust allow me to write code that allows certain kinds of race conditions like lossy algorithms?
Benjamin Cronce I guess there are many race conditions which are blocked by the compiler due to the single owner principle, but you can always use unsafe doc.rust-lang.org/1.5.0/book/unsafe.html
Excuse me, am i right, that for async/await need some runtime >? does it mean lose 0 cost abstraction >? and what's about compiler errors for not safety async code ?
There is always SOME runtime. People generally mean a MINIMAL runtime when they say C or Rust has no runtime. With async/await, as the speaker explained around the 13min mark, there is some scheduling overhead with the event loop. What's cool though is that the Futures themselves are zero cost abstractions and because Rust does NOT subscribe to the m:n model (as Go does), the language itself still does not pay for this runtime.
This reminds me of when people talk of not using a framework, but really you're always using a framework, even if it's something you cobbled together yourself. In the case of Go, you're stuck with the event system that is built into the language, but with Rust you can pick or create one tailored to your needs. Though it can be convenient to just be told "here, use this".
"Zero cost abstraction" should mean that the cost is zero because the abstraction is summed to zero at compile time. I think that the Rust guys are abusing the term. It should be called "user parity" abstraction or "as good as you" abstraction.
@@jorickcaberio5367 Sure, there are nice abstractions to deal with the difficult problem that is async programming. Doesn't mean you should be ignorant of why they exist and what problems they solve. At present, most languages contain enough ammo to easily shoot yourself in a foot when it comes to race conditions.
She never even mentioned these topics... and then people complain about these topics being brought up for no reason. It seems the same people complaining about these topics being brought up too often are the ones bringing them up too often. Lol.
I've seen a number of people struggling with writing async code over the past year or so. This talk was a really great walk through of the history of async I/O in Rust leading up to the current state of things. Thank you!
Very cool, informative, entertaining and good to follow talk :) Nice!
Great talk, very informative. Been wanting to learn more about Rust and how async is implemented with it. Also loved the Bojack reference 😊.
drat, i missed it. where was it?
@@circularly 10:38 :)
Good talk, thanks!
Great talk!
Just stopped by to say the thumbnail for this video looks metal as fvck.
Really really hard to read the code samples on the slides... higher luminance contrast please.
I've been obsessed with concurrency since I was 10. I think it's fun and relatively easy if designed correctly. If you limit how a object can get in a certain state to a small bit of code, instead of strewn all over the system, any time there is an issue with that state, you only have to look at a little bit of code.
Sometimes it is desirable to lose data in order to gain scalability. Will Rust allow me to write code that allows certain kinds of race conditions like lossy algorithms?
Benjamin Cronce I guess there are many race conditions which are blocked by the compiler due to the single owner principle, but you can always use unsafe doc.rust-lang.org/1.5.0/book/unsafe.html
Excuse me, am i right, that for async/await need some runtime >? does it mean lose 0 cost abstraction >? and what's about compiler errors for not safety async code ?
There is always SOME runtime. People generally mean a MINIMAL runtime when they say C or Rust has no runtime. With async/await, as the speaker explained around the 13min mark, there is some scheduling overhead with the event loop. What's cool though is that the Futures themselves are zero cost abstractions and because Rust does NOT subscribe to the m:n model (as Go does), the language itself still does not pay for this runtime.
thanks, Srishan. Now i found a discussion about Scheduling model in Rust: news.ycombinator.com/item?id=6980946
This reminds me of when people talk of not using a framework, but really you're always using a framework, even if it's something you cobbled together yourself. In the case of Go, you're stuck with the event system that is built into the language, but with Rust you can pick or create one tailored to your needs. Though it can be convenient to just be told "here, use this".
She elaborates the concept of zero-cost abstractions a bit at around 19:40
That discussion discusses a research version of Rust. Rust was finally released in 2015, and doesn't have the Task model anymore.
Hope i can join rust bridge workshop next time you do it in Portland.
Cool
"Zero cost abstraction" should mean that the cost is zero because the abstraction is summed to zero at compile time. I think that the Rust guys are abusing the term. It should be called "user parity" abstraction or "as good as you" abstraction.
Terrible crowd, some of her jokes were really funny yet no one laughed. Great presentation nonetheless.
Terrible crowd... or good mic setup?
@@andersarpi5230 I actually went straight to the description for an Amazon Affiliate link on that mic...
>her
Obviously Java & Mocha are not for you, because you love tea. 😎
build a linux-like kernel with it !?
Already done, (multiple times): www.redox-os.org/ os.phil-opp.com/ github.com/thepowersgang/rust_os
I will never understand what problem has people with async programming. It's quite easy to reason about
Those who think it's easy usually introduce all the bugs that other people have to fix...
@@julkiewitz not if you use a language like Erlang
@@jorickcaberio5367 Sure, there are nice abstractions to deal with the difficult problem that is async programming. Doesn't mean you should be ignorant of why they exist and what problems they solve. At present, most languages contain enough ammo to easily shoot yourself in a foot when it comes to race conditions.
So nothing about async in a talk about async?
I very much don't agree with Katy's opinions about feminism, sexism and so on but her talk is great!
She never even mentioned these topics... and then people complain about these topics being brought up for no reason. It seems the same people complaining about these topics being brought up too often are the ones bringing them up too often. Lol.