Nice so far. Just a small nitpick, at 13:20: Pretty sure that "Auto-Implementation" is already (pretty much) used for something else, and even ignoring that thing there's other mechanisms that could be named the same. Auto-Trait-Implementations is reserved for things that a user usually doesn't interface with directly, stuff like Sync (which gets imemented automatically on any type that is made up out of elements that implement Sync), Send etc. These get implemented entirely without user interaction, while the things refered to in the talk still need to be explicitly opted in, even if that is with minimal boilerplate. These traits refered to in the talk, eg Clone, Copy, Hash etc, are called "Derivable traits". There's also YET ANOTHER mechanism, called "Banket Implementations". These are also powerful and interesting. One example is the Conversion Traits "From" and "Into", which can handle eg conversions between &str and String. As the documentation of these mentions you usually only want to Implement "From" on the target type, this will automatically create an implementation of "Into" on the source type via Blanket Implementation. So, if you implement "From for String" the compiler will generate a perfect implementation of "Into for &str".
15:30 according to Rust docs; use From for imlementation and use Into for trait bounds. Examples: Implementing From you can see in the video: impl From for SquareContent { ... } Trait bounds for Into only accepts parameters that are castable to SquareContent. we implemented From earlier so we can pass u8 because we know how to make SquareContent from u8; fn my_super_function(param: T) -> SquareContent where T: Into, { ... }
The essential ideas behind the traits are explained by a passioned developer. Thank you, this is the first time that I see a trait is more than an interface.
I'm a C# and Java programmer, and I would like to use them too. As one of the attendees pointed out, Rust traits are similar to typeclasses in Haskell, which have been around since the 90s at least. (I am familiar with them in Haskell.)
I was confused by the `From`/`into` until it dawned on me that you are _not_ doing a reverse operation! It was subtle for me. Using pseudo-code, `Widget::From(1)` can simply be re-stated as `1.into()` which returns the same widget. This way, its a different syntax for writing the same thing that can come handy in some situation, e.g more ergonomic api with chained operation. (This would be very different from say `Widget.into()` to return a 1 but thankfully thats not whats happening here. )
I'm definitely confused with implementing into_iter. I'm understanding that you can add "parameters" to interfaces in some sense. Essentially, only as types. All I can see from the example is a daunting pile of various versions of "into" and "iter", with various joining characters. It makes sense to inform the compiler that the calling code will get an item of a specific type when iterating. It makes sense to reuse the into_iter implemented on an array. I'm having difficulty understanding the function. If I'm understanding the code right, we're saying we're going to return the same type that calling into_iter on an array of length 9 would return? Are these identical? IntoIterator::Into_iter(self.board_content) self.board_content.into_iter()
Yes, IntoIterator::Into_iter(self.board_content) and self.board_content.into_iter() should be identical identical(as well as Self::into_iter(self.board_content), and ::into_iter(self.board_content) I believe)
Hi great talk, thank you. Small thing at 18:00, not really automatic magic, more fully qualified syntax since default doesn't have a Self receiver as I just learned. It threw me and I didn't understand other than the obvious thing happening. It is like ::default().
"Eine Fähigkeit auf Basis eine anderen Fähigkeit ableiten" is what it sounds like to me. To derive a trait based on another trait, or something like that.
Rainer seems like a great guy. Helpful, clear, and humble.
Awesome! The speaker has a great passion for Rust.
Yes, the passion is showing. Great.
Nice so far.
Just a small nitpick, at 13:20: Pretty sure that "Auto-Implementation" is already (pretty much) used for something else, and even ignoring that thing there's other mechanisms that could be named the same.
Auto-Trait-Implementations is reserved for things that a user usually doesn't interface with directly, stuff like Sync (which gets imemented automatically on any type that is made up out of elements that implement Sync), Send etc.
These get implemented entirely without user interaction, while the things refered to in the talk still need to be explicitly opted in, even if that is with minimal boilerplate.
These traits refered to in the talk, eg Clone, Copy, Hash etc, are called "Derivable traits".
There's also YET ANOTHER mechanism, called "Banket Implementations". These are also powerful and interesting. One example is the Conversion Traits "From" and "Into", which can handle eg conversions between &str and String. As the documentation of these mentions you usually only want to Implement "From" on the target type, this will automatically create an implementation of "Into" on the source type via Blanket Implementation. So, if you implement "From for String" the compiler will generate a perfect implementation of "Into for &str".
This is the most enthusiasm i Have ever seen for someones cause
15:30 according to Rust docs; use From for imlementation and use Into for trait bounds.
Examples:
Implementing From you can see in the video:
impl From for SquareContent { ... }
Trait bounds for Into only accepts parameters that are castable to SquareContent. we implemented From earlier so we can pass u8 because we know how to make SquareContent from u8;
fn my_super_function(param: T) -> SquareContent
where
T: Into,
{
...
}
I’d like to take a moment to say that a tied tic-tac-toe match is called a “cat’s game”
The essential ideas behind the traits are explained by a passioned developer. Thank you, this is the first time that I see a trait is more than an interface.
Rust is so ahead of the curve, as a C# guy I’m kinda jealous
I'm a C# and Java programmer, and I would like to use them too.
As one of the attendees pointed out, Rust traits are similar to typeclasses in Haskell, which have been around since the 90s at least. (I am familiar with them in Haskell.)
I love your energy Rainer. That’s a great talk that I will recommend.
I was confused by the `From`/`into` until it dawned on me that you are _not_ doing a reverse operation! It was subtle for me. Using pseudo-code, `Widget::From(1)` can simply be re-stated as `1.into()` which returns the same widget. This way, its a different syntax for writing the same thing that can come handy in some situation, e.g more ergonomic api with chained operation.
(This would be very different from say `Widget.into()` to return a 1 but thankfully thats not whats happening here. )
Exactly, having "impl From for Sausage" doesn't magically implement a conversion that would allow us to make the poor pig back from our meal.
loved this! genuinely helped me understand traits better
Thank you so much. I filled some gaps about traits by watching the video.
This is a very in-depth video about rust features. Thanks!
What an incredible educator.
This is an absolutely amazing talk!
Wait, did you said Ferris cake? I want one please
I'm definitely confused with implementing into_iter. I'm understanding that you can add "parameters" to interfaces in some sense. Essentially, only as types.
All I can see from the example is a daunting pile of various versions of "into" and "iter", with various joining characters.
It makes sense to inform the compiler that the calling code will get an item of a specific type when iterating. It makes sense to reuse the into_iter implemented on an array. I'm having difficulty understanding the function.
If I'm understanding the code right, we're saying we're going to return the same type that calling into_iter on an array of length 9 would return? Are these identical?
IntoIterator::Into_iter(self.board_content)
self.board_content.into_iter()
Yes, IntoIterator::Into_iter(self.board_content) and self.board_content.into_iter() should be identical identical(as well as Self::into_iter(self.board_content), and ::into_iter(self.board_content) I believe)
Awesome explanation for C# coming developers... from C# developer !!.
Strong Christolph Waltz vibes
Well, he's Austrian so that would make sense. Excellent energy. Really commands your attention and makes you hyped (or scared) lol.
That feeling when Dr. Schultz is teaching you Rust...
Oh, man. I need to learn German to understand traits? XD
Just kidding. Awesome talk. I would recomend it to all people looking into learning Rust.
What a mind blowing talk!
The speaker is awesome. 🤓. I really liked the code examples.
Hi great talk, thank you. Small thing at 18:00, not really automatic magic, more fully qualified syntax since default doesn't have a Self receiver as I just learned. It threw me and I didn't understand other than the obvious thing happening. It is like ::default().
Can someone give me the German at 33:16 when talking about From implying Into?
"Eine Fähigkeit auf Basis eine anderen Fähigkeit ableiten" is what it sounds like to me. To derive a trait based on another trait, or something like that.
very good examples
Great talk, I learned a lot from it!
Great talk! I like to always include the return statement though. It makes code more readable I think.
Cool! Amazing talk! 🦀
Thank you very much for this very clear talk.
Good!
👏👏👏
I want to double like
🍺
"let me just say one sentence in german so that the whole audience gets it."
Says it.
Doesn't translate.
Wut?
42 Comments
😆
❤️