I think this talk needed to go in earlier discussing move semantics, as otherwise the difference between iterating over Vec vs &Vec is very confusing - the key observation being that IntoIterator *converts* a Vec into an iterator over the T values, such that the original vector is moved out of and no longer available. Most Rust tutorials and books I have seen hand-wave over this stuff in the interests of presenting iteration as super ergonomic, which it is, but I was very confused by this until I worked out what was actually going on
Good talk, Nicholas could work on his slides a little bit more though (syntax coloring, side by side code comparison, more meaningful function names etc. and add short 5min intro about language basics)
Great Job. Would love to have more in-depth videos such as these focused on application. Would help us adapt rust easily and better correlate to the features of classic programming languages such as C/C++
One thing I would have mentioned when covering `.and_then()` at 36:00 is that `and_then()` is just mbind (monadic bind), i.e. the `>>=` operator from Haskell. This becomes pretty obvious when you closely examine its signature, but it was less obvious for me when I first saw it, because of "strange" (but sensible) naming. So you can chain functions-which-may-fail with .and_then()s, the same way you can chain promises in js/ts, or the way `do` construct sugars monad bindings in Haskell.
lol, why did they vote traits over ownership? difference between functions.methods.traits and functions.methods.methods is easy and could be left as an exercise to the reader. :D I can't find the part after the coffee break. Anyways, good talk.
I understand why the guy is confused about Result's T and E being in the order that they're in, since most other languages do it in the reverse (likely because of Haskell starting it). My question is why the heck they were in the other order to begin with. I THINK it's because it's inspired by or actually derived from the Either type, where "right" sounds more like it should be the primary type than "left", and so it was made the primary side. But you could have named it "first" and "second" or "primary" and "secondary" or something like that and made it so that the first type listed is the primary type. This has bugged me since the first time I saw it, and I was so proud of Rust for doing the obvious thing.
Open question regarding iter() at 37:30 I’ve just started with Rust and find myself often using iter() to go from result just to get the nice functional methods found on Iter that’s not in Result/Option. It will obviously only iterate 0-1 object so it feels a bit bad/strange to “iterate” it. Is it idiomatic/normal/ok to do this? An alternative would be to make the same code more procedural which I don’t like quite as much. Since this is a TH-cam comment section I’m sure people has opinions? :)
Good question! In my experience using Option::iter() or Result::iter() is indeed not the idiotmatic way. And I'm surprised to hear you say that Option and Result don't have similar functional operators because they do! :) Option has map, map_or, map_or_else, and, and_then, zip, copied, flatten and many more. In fact, at 30:09 he uses Option::map which is the idiomatic way to model such a thing Option: doc.rust-lang.org/std/option/enum.Option.html Result: doc.rust-lang.org/std/result/enum.Result.html
Does this "wrapping-into-option" hit the performance (i.e., when using iterators which seem to wrap every value into an option just to indicate some end of list)? Or do they somehow get compiled away?
They're generally as "zero cost" as possible. Let me put it this way: If your function needs to be able to return either something or nothing at all, you obviously need to encode that information somehow. In that case there's no faster option than using Option But often they are also just optimized away quite well: e.g. Option has the same representation as a simple pointer to T. Also because predicates and such get "compiled into" the functions they're passed to they are pretty much guarenteed to be inlined. So `iter().map(|x| if x > 1 {Some(x)} else {None}).filter(|x| x.is_some())` will (with optimizations on) never construct an Option object
Great talk, badly designed slides although their actual content was good. Some of those slides could be combined (especially comparing C++ vs Rust) so that the talker didn't have to switch between them all the time.
Unfortunately, your C++ examples are very misleading. For example, the code you showed at 42:03, could be written in a safer and more elegant form using C++ as the following: void ping_all(const std::vector& foos) { for (const auto& foo : foos) { foo.ping(); } }
The thing is not about what should be done, but about what could be done. You should introduce mutexes, but you could go without them out of inexperience or basically any human error. You cannot do it without mutexes in safe Rust.
Ergonomic? Rust is anything but that. However, the contribution of borrow checking is really significant. Lifetimes? Absolute kludge. This actually motivated me to brush off ANTLR and explore how else this could be handled, as well as polymorphism. The choice between hacks or unending boilerplate is not an attractive one.
This is just my personal opinion, but I hope it helps you with your presentations. When you are speaking you just way way too many unnecessary words. You speak using the word "like" in places where it is not necessary. You pause and say "uhh," or "uhm" and so, etc. You say "actually" too much. You put in words to exaggerate something, when it is not necessary. That all being said, I can only imagine it is difficult to explain the concepts of rust-code to people that have no idea how rust-code works.
The talk could have been even more amazing with much better preparation. Speaking in front of audience is a skill and something he should train for, the "uhh" "umm" and all these sounds are quite annoying. I still haven't found any good resource explaining the rust's spirit. They all show examples and explain a bit without saying the Why. (yeah mutable variables are bad but all languages have that and it's still working, tell me why it's better instead... and why I just can't use const in C/C++/javascript/... that has the same result) They should also stop comparing it with other languages. That's so wrong. It's like learning a new speaking language, at one point you just need to stop translating to your native language to actually learn otherwise you just learn your native language with different words. And that also makes the assumption the listener knows those, that isn't always true.
I wish the official rust book was this clear. Instead it feels like it was written by a woman(or a feminine guy) trying to explain you stuff through real world analogies as if you were a child.
![ค้างคืนโรงเก็บกระสวยอวกาศร้างกลางทะเลทราย [Around The World Ep. 3]](http://i.ytimg.com/vi/E5bWZQhABJE/mqdefault.jpg)
This video was the thing that actually got me to finally understand Rust. I cant say how much this has helped me. I watched every second of it.
V Xbox, x has, g, and g, x Yaz g
The only
The only time - 90
I caught a
Fyz9f
I think this talk needed to go in earlier discussing move semantics, as otherwise the difference between iterating over Vec vs &Vec is very confusing - the key observation being that IntoIterator *converts* a Vec into an iterator over the T values, such that the original vector is moved out of and no longer available. Most Rust tutorials and books I have seen hand-wave over this stuff in the interests of presenting iteration as super ergonomic, which it is, but I was very confused by this until I worked out what was actually going on
I'm only 14 minutes into this talk, but I'm already picking up on influences from Haskell.
@Niranjan Raju scala is jhaskell, rust is chaskell
I love that until I start thinking Haskelly and run into things not in Rust. Why won't they just add GATs and Higher Kinded Polymorphism /rant-over
@@jeffparent2159 They are coming... eventually. They're super hard to get right that's why they take such a long time
I wonder how much of that is from ML, because rust is pretty heavily influenced by ML, the compiler was even original in OcaML
Good talk, Nicholas could work on his slides a little bit more though (syntax coloring, side by side code comparison, more meaningful function names etc. and add short 5min intro about language basics)
Great Job. Would love to have more in-depth videos such as these focused on application. Would help us adapt rust easily and better correlate to the features of classic programming languages such as C/C++
The speaker is phenomenal, and really groks the subject.
makes a lot of sense considering he's working on the team that makes it 😂
One thing I would have mentioned when covering `.and_then()` at 36:00 is that `and_then()` is just mbind (monadic bind), i.e. the `>>=` operator from Haskell. This becomes pretty obvious when you closely examine its signature, but it was less obvious for me when I first saw it, because of "strange" (but sensible) naming.
So you can chain functions-which-may-fail with .and_then()s, the same way you can chain promises in js/ts, or the way `do` construct sugars monad bindings in Haskell.
Great talk. May i ask where i can get the slides as ownership is not covered, like to take a look at that piece ?
Really enjoyed this viideo. Been looking for a while to find something that went a bit deeper into some details of rust. Thanks
great talk from a very knowledgeable speaker! glad he's able to explain to outsiders the great benefits and all
I think code listing in 46:50 needs a derefernce inside closure `.filter(|x| *x > 1)` or a readable ref '.filter(|&x| x > 1)'
For me '.filter(|X| X > &1)' worked (borrowing the number value)
lol, why did they vote traits over ownership?
difference between functions.methods.traits and functions.methods.methods is easy and could be left as an exercise to the reader. :D
I can't find the part after the coffee break.
Anyways, good talk.
Exactly. So frustrating.
Indeed...Understanding Ownership is so basic, so crucial, that it comes BEFORE any fancy thing in Rust !
I understand why the guy is confused about Result's T and E being in the order that they're in, since most other languages do it in the reverse (likely because of Haskell starting it). My question is why the heck they were in the other order to begin with. I THINK it's because it's inspired by or actually derived from the Either type, where "right" sounds more like it should be the primary type than "left", and so it was made the primary side. But you could have named it "first" and "second" or "primary" and "secondary" or something like that and made it so that the first type listed is the primary type. This has bugged me since the first time I saw it, and I was so proud of Rust for doing the obvious thing.
Open question regarding iter() at 37:30
I’ve just started with Rust and find myself often using iter() to go from result just to get the nice functional methods found on Iter that’s not in Result/Option. It will obviously only iterate 0-1 object so it feels a bit bad/strange to “iterate” it. Is it idiomatic/normal/ok to do this? An alternative would be to make the same code more procedural which I don’t like quite as much.
Since this is a TH-cam comment section I’m sure people has opinions? :)
Good question! In my experience using Option::iter() or Result::iter() is indeed not the idiotmatic way. And I'm surprised to hear you say that Option and Result don't have similar functional operators because they do! :)
Option has map, map_or, map_or_else, and, and_then, zip, copied, flatten and many more. In fact, at 30:09 he uses Option::map which is the idiomatic way to model such a thing
Option: doc.rust-lang.org/std/option/enum.Option.html
Result: doc.rust-lang.org/std/result/enum.Result.html
any follow up video that we can refer to after completing this one?
I'm seeing this for the second time. It's a very good review!
Does this "wrapping-into-option" hit the performance (i.e., when using iterators which seem to wrap every value into an option just to indicate some end of list)? Or do they somehow get compiled away?
They're generally as "zero cost" as possible. Let me put it this way: If your function needs to be able to return either something or nothing at all, you obviously need to encode that information somehow. In that case there's no faster option than using Option
But often they are also just optimized away quite well: e.g. Option has the same representation as a simple pointer to T. Also because predicates and such get "compiled into" the functions they're passed to they are pretty much guarenteed to be inlined. So `iter().map(|x| if x > 1 {Some(x)} else {None}).filter(|x| x.is_some())` will (with optimizations on) never construct an Option object
Knowing how awesome rust really is I feel this person woefully undersells it lol
Great talk, badly designed slides although their actual content was good. Some of those slides could be combined (especially comparing C++ vs Rust) so that the talker didn't have to switch between them all the time.
Awesome talk
Does anyone knows where to get the slide of this session ?
Very informative, thanks a lot!
30 min in and I'm thinking maybe I should learn the language first, before allowing myself to get even more confused.
I hate people playing on their phone in a talk. This is very disrespectful.
why are people sitting awkwardly around him LUL
Unfortunately, your C++ examples are very misleading. For example, the code you showed at 42:03, could be written in a safer and more elegant form using C++ as the following:
void ping_all(const std::vector& foos) {
for (const auto& foo : foos) {
foo.ping();
}
}
14:57 With “positive”, did you mean non-negative?
what's the difference?
@@aykxt 0 is non-negative but not positive.
7:30 why would it be mutated? are we talking about a multi-threading app? why is there no mutex/semaphore then?
The thing is not about what should be done, but about what could be done. You should introduce mutexes, but you could go without them out of inexperience or basically any human error. You cannot do it without mutexes in safe Rust.
@@Igigog agree, thanks
This was really noice!! Thanks! Btw, is the speaker that guy from the Split movie? 😅
24:44 not err => return err but Err(err) => return err
You don't need the return keyword I think
This is, kind of like, a good talk
I think it's, kinda like, trying to be like, a good talk, but it kinda like, fails, on like, the communication side of like, things.
nice talk
coool thanks Man
Ergonomic? Rust is anything but that. However, the contribution of borrow checking is really significant. Lifetimes? Absolute kludge. This actually motivated me to brush off ANTLR and explore how else this could be handled, as well as polymorphism. The choice between hacks or unending boilerplate is not an attractive one.
Nice content
9:26 troop ready
Monads, monads everywhere
This is just my personal opinion, but I hope it helps you with your presentations. When you are speaking you just way way too many unnecessary words. You speak using the word "like" in places where it is not necessary. You pause and say "uhh," or "uhm" and so, etc. You say "actually" too much. You put in words to exaggerate something, when it is not necessary. That all being said, I can only imagine it is difficult to explain the concepts of rust-code to people that have no idea how rust-code works.
i think.u r missing the entire talk
The talk could have been even more amazing with much better preparation. Speaking in front of audience is a skill and something he should train for, the "uhh" "umm" and all these sounds are quite annoying.
I still haven't found any good resource explaining the rust's spirit. They all show examples and explain a bit without saying the Why. (yeah mutable variables are bad but all languages have that and it's still working, tell me why it's better instead... and why I just can't use const in C/C++/javascript/... that has the same result)
They should also stop comparing it with other languages. That's so wrong. It's like learning a new speaking language, at one point you just need to stop translating to your native language to actually learn otherwise you just learn your native language with different words.
And that also makes the assumption the listener knows those, that isn't always true.
why are you constantly creating new programming languages
my brain is too lazy
Fortran68 is all you ever need
@@NoNameAtAll2 I would say C is all you ever need instead
@@alainterieur5004 C is for people too dumb for assembly, which is for people too dumb for machine code.
@@nilstrieb yes and then you have to rewrite your code for every cpu architectures possible
big brain
@@alainterieur5004 as I said, most people are too dumb for that
I wish the official rust book was this clear. Instead it feels like it was written by a woman(or a feminine guy) trying to explain you stuff through real world analogies as if you were a child.
wtf?