9:40: As a fellow Haskell and Rust enthusiast, I must point out for extra completeness that liftA2 (from Control.Applicative) and on (from Data.Function) can shorten this even further: wnew = liftA2 W `on` fallible Great video, and the Haskell reference was the cherry on top.
Infallible is actually a workaround for the limitations of Rust syntax and type system when it comes to the ! never type. It is likely one of them will be made just alias for the other somewhere down the line.
@@KohuGaly Glad to see I'm not the only one who sees an issue with this. I find it bizarre to use a special type just to circumvent a problem that's fundamentally caused by forcing a function to return an error when it's not possible for that to happen.
Thiserror is a good choice for libraries, anyhow makes sense for applications. You shouldn't use anyhow in libraries (since it forces any applications using it to use anyhow too), but thiserror produces normal enums, it just saves boilerplate. You can use it for applications too, although some people prefer the ease and context capabilites of anyhow.
The advantage of anyhow is that you don't need to handle specific error cases, you can just say "oh whatever, when there's an error I'm just gonna print the error message to the screen" or something like that. On the other hand, if you actually do care about which specific error you get (say for example you want to recover from the error in different ways depending on what happened), then using enums / thiserr is the way to go! And for library code, probably very rarely want to use anyhow (and never want to have an anyhow::Result exposed from your API!).
5:32 I was going to bring up this exact point and then you said it. There have been tons of times where I've returned `Result` specifically because, to me, there is a semantic difference between "I have nothing to return to you" and "this operation *failed*."
If you don't have a need for an error type, then you should use an Option Imo. If there is a semantic difference between 'I have nothing to return to you' and 'This operation failed', return Result or if there are multiple ways to return fail specify an error. If there is only a single way by which the function does not return a value you should use an option.
That last line blew my mind! A result without an err is isomorphic to a bool. Pretty new to rust, but result and option seem a LOT better than doing "if data != null" checks in JS
These videos are incredible. It's so hard to find programming videos for any language that don't assume the viewer is a total noob to programming in general. I love this because, even though I'm already familiar with Option, Result, From, and all the other std library stuff, I didn't know about thiserror and anyhow. I just hope the rust community is a big enough audience to sustain this channel.
Coming to Rust from Haskell just wanted to say I appreciated the brief digression into what this would look like with do-notion in the Either monad. I really respect Rust's unified approach to using Result everywhere rather than exceptions. Got a lot out of your video, thanks.
I will chime in with the other comments. You have found a great niche in the Rust educational landscape. Please continue exploring more and more tricky Rust concepts. Thank you for your work !
You have a flavor of type theory / category theory when describing the isomorphisms of Result ~ Option and Result ~ T. I'm curious to watch your other videos if you would cover things such as dependent types, const N: usize, and what GATs map to in the realm of type theory. Thanks for the video!
One thing that drives me absolutely bonkers nuts is when libraries have custom error types that don't implement the Error trait. PLEASE if you are making a library implement the Error trait on your error types, without it being able to generically handle errors is literally impossible.
Small problem with implementing std::error::Error: Sometimes std does not exist. For libraries intended to be usable in low level environments where many of the functions of std don't even make sense, it's common to target core instead. Now, the Error trait is not one of those things that doesn't make sense in a low level context... which is why so many have wondered why it wasn't in core to begin with, and now it's _beginning_ to appear in core, but also nightly only.
@@angeldude101 In the meantime, what is the general rule for low level envs? I'm starting to do some embedded systems stuff with rust on a pi pico. Just panic?
Thanks Logan, great video. I'm currently working in another language and miss using Rust, and videos like these keep me fresh and up-to-date on the language.
This might be pedantic but it was fun to learn about: Never isn't exactly the bottom type. It is an empty type, with no values, but the RFC making it a full type explicitly says that it isn't the bottom type, because it's not a subtype of anything. It coerces to any type, but it isn't a subtype of anything. And this is awesome news for us: otherwise Vec would be a subtype of Vec for any T, and that means we wouldn't be able to write to a Vec. Subtyping in Rust is pretty much limited to lifetimes, which is what seems to allow stuff like Vec to be covariant in rust even though it would have to be invariant in a language like Kotlin.
I have to confess I am always learning so much about Rust with all your videos!! The more I watch, the more I realise how wonderful and powerful Rust is as a programming language. Thank you so much!
The real gem in this video is as the derive_more crate. The rest was great as well, but I felt at home with most of this. It’s nice to just hear it in detail and twist and turn concepts around an look at them from different direction. It really helps solidify the ideas.
Your Rust videos is a gem. Errors is a hot topic and extremely undervalued here on youtube. It should be covered more deeply. Errors in Rust is something that very much differs from other languages
Note that the compiler will correctly infer Vec for T in the Result if you just provide Result. You could simplify Ok(Self(v?)) even further with a `.map(Self)` instead :)
Your content is VERY helpful in reasoning about rust! I shared your channel on 2 disc servers to potentially help others...and to give back to you for your hard work! Keep it up, man
Awesome video as always! It should be noted that Result also has a rich meaning - if this function returns, there has been an error. For example, a program that loops forever until some error occurs, like a server. Although, in this context, the name "Infallible" leaves a lot to be desired x)
Wow this is exactly the kind of video I was hoping for. Thinking about Result as a generalization of Option is a really helpful mindset for thinking about the two types. Even if it's a little more nuanced than that, I think I get too hung up on the extra context that the "Ok" and "Err" names seem to provide. It always bothered me that it's accepted convention for Either to be used this way in Haskell, and I always thought it was just a chance for a "Right is right, lol" joke. But this video really clearly illustrated how helpful of a framework that is.
Maaan.. I've said this on a previous video of yours, but still the best rust content on YT! I think what makes your videos great is that you actually explain the theory and logic behind the type system, so that what-s and why-s are a lot simpler to understand.
Your Rust videos remind me very much of Meyers' two Effective C++ books (which I devoured when they came out). I really look forward to more in this vein. Thank you.
I saw this - and I thought: "WOW I NEEDED THIS I WISH I WAS SUBBED TO THIS BIG CHANNEL YEARS AGO". They I saw that I am subbed already. Then I saw that your channel is one of those small channels which I felt needed 20 hours to binge. Then I saw the comment underneath which also says the same T_T This channel will be huge. I'm calling it.
Thank you so much for putting this video together. It's very rare to see videos where programmers dive into the mental models of how to use features and patterns so that alone is incredibly helpful. That aside, the relationship you've established between Result and Option makes a lot of sense, I was wondering if the difference between the two was just that in one of the them you can access an `Err` but this explanation made me understand the uses much better. Hope you continue to make cool videos like these! 🙏
Creating and dealing with errors in Rust has always been difficult for me. Thanks to you, I know understand them a lot better. I'll definitely look into the thiserror and anyhow crates.
Awesome video, I'm learning rust, I struggle a lot when working with results (how to unwrap, chain them...etc), videos like yours are very helpful. Thanks 🙏
That was really really good stuff. I’ve never used any of the error crates because I’ve always strived to handle/propagate errors before they hit main. Some notes that I think would have been very beneficial (albeit philosophically) is that errors and the result/option enums are there to represent invalid state. I think you are correct that None should be inferable, but the purpose of Err is to announce and detail what erroneous state has occurred. Take serde_json::Error the error is a enum but for relevant variants it contains line and column information. Great for syntax error but useless or EOF (empty json) The last thing IMHO is that not all errors should be recoverable. For example if you are converting a &[u8] to a string and a non-UTF8 character is provided perhaps you can gracefully handle the error but if recovery is impossible then failure should be defined by the program. Rust is a systems language an OS is not a guarantee. If failure is inevitable then provide relevant context before panic!(). I believe this is the reason why .unwrap and .expect panic on Err. How do you allocate E to T when the variable is expecting T. A case of UB for sure better to panic than let it hit memory
I really love these videos. The precision with which you approach analyzing how and why a piece of code does what it does, and in describing it, is something I have actually been looking for. Along with explaining computation theory with things like data structure isomorphisms, explaining side points like the Never type and the reasons for its existence... it feels like what you are going for is a combination of 'know your tools', with knowing the topic and the practical application. Impressed by how you combine these three. Looking forward to seeing more. Definitely subscribing.
12:12 wow damn, thanks for the traversal tip, I did not know Rust has it🎉 It’s very useful in cases when you actually don’t need to accumulate all potential errors from the collection and just fail when first occurred
I watch this video every time I'm about to write a library to remind myself how to do it right, and every time I learn and remember a bit more. My journey of errors was Box, anyhow, thiserror, and I'm probably right in that most crustaceans go through this cycle lol. Great vid, thanks. Wish I had it when I started with rust.
Sooo good explained: Love how you peak into architectural misshapes everybody should take to their heart when writing return types. One writes for the usage, and being sloppy on return types and even returning too little sometimes just frustrates the users, so some extra thought is always welcome :) ❤
Great video! I'm new to Rust and this helped me out a lot with a toy project I'm working on where I was having issues chaining iterators and dealing with flip flopping between Options and Results. Looking forward to future Rust videos!
In the higher-level areas of my code, I like to separate errors (which now represent many processes) as being in two classes: recoverable and unrecoverable (which is a bit of a misnomer). Unrecoverable errors are when the code/program is missing some vital information, and, unless it's somehow fixed by something or that entire subsystem is reset, the program must fail. Recoverable errors are like I/O errors, where it's more like "This is a benign error that I can just try again at, but if it persists, then there might be a problem with the environment that the user should know about, which is why I'm telling you now." I also prototype with anyhow::Error, I just use it blindly everywhere in a module as I design it. Once I've built up the design, I go in, look at all possible errors, and design my error types properly, rather than trying to guess what I think my API might look like when it's done. I specifically do not represent an invalid program state in errors, as Rust makes invalid program states impossible. So if you wrote code that can have an invalid state, you're just writing buggy code and should remodel your design. Sometimes if you catch yourself writing an error, you can stop yourself to think "wait, do I really need to make this a runtime decision?"
brief note on 10:40 - the return type of a `return` expression has historically been a compiler magic version of unit, and in fact that’s one of the things that has been holding back the stabilisation of `!` as a language feature
Have I ever used Rust?: No. Will I ever use Rust?: Probably not. Do I know most of the things he is talking about?: Definitely not. Did I enjoy the video?: Yes
A little note at the end - Result can be freely destructured as Ok(foo) is an irrefutable pattern (due to the Err variant being impossible to construct), and (at least IIRC) the optimiser (possibly as a result of NVO?) will unwrap the result at binary level in this case as well
@@_noisecode yes, that's one of the things I'm saying - the other is that you are allowed to do it by the rules of *Rust* as well (e.g. Ok(true) and Ok(false) are typically bit-compatible with true and false (as long as E is 1 byte or smaller, and fits into NVO), but you aren't allowed to destructure them freely if E is not !) I see how the second part of my statement is confusing; I meant it is unwrapped _at all times_ - due, as you note, to the transparency of the ABI in this case
I appreciate that you styled your animations after 3Blue1Brown - maybe using his graphics library? - excellently put, super well documented on screen, and interesting. Keep them coming!
I love the idea of having a safe program, but it really irritates me when I have a tree of functions that returns a result, and I have to set every single function to return a result. Maybe I'm just a bad at Rust though 😂
"You're thinking: If only we were writing Haskell, then we could use do-notation in the Either monad" I understand this is a joke. I really do. But damn, I was literally constructing a comment in my head about how neat this is in Haskell...
this is what exactly I thought about about result and option by my intuition when I first gone through the rust docs, especially for the result enum as generalization, nevertheless great video, keep going.
I was uncompfortable with Result for some time because of the confusing builtin syntax around the type not the Result type itself. There are so many different way of interacting with them like unwrap and ? and OK() and all that. It took me some time to actually find a resource that packed all the different ways of interacting with Result in one place and when to use which one. The result type propagation of ? was particularly confusing at first because it seems like implicit magic if you don't know what you are looking at. That was some time ago now though (4 years or so). So I assume the explanations of this are probably much easier to find and well written compared to back then.
Great video as always! I would love to hear you talking about manual v-table implementations. I know about two crates that use them internally (anyhow and bytes) and have some general idea of how it works, but I would love to hear an in-depth explanation of its tradeoffs, details, design patterns and maybe event unstable std APIs `std::ptr::{Pointee, DynMetadata}`.
i dont think the none option should be used to indicate failure, instead i like to think of it as indicating that the value youre asking for does not exist. HashMap::get returns none when theres no value for the given key. i think using a result (even when theres only 1 possible kind of error) when theres a chance the function fails makes more sense and is more readable
I wish your channel had twenty hours of videos like this to binge.
on it
@@_noisecodeim excited but don’t rush them, they’re so good at this level of quality :)
same, these might be the most interesting Rust videos on YT (sorry Jon, sorry No Boilerplate)
Glorious! The Haskell aside is the cherry on top for me 👌👌
St Rust 🙏
Your videos are all so high quality! Your Videos are Result
legendary comment
@@_noisecode
let your_videos = Result
When he uploads, there is only one Option, until there is none
9:40: As a fellow Haskell and Rust enthusiast, I must point out for extra completeness that liftA2 (from Control.Applicative) and on (from Data.Function) can shorten this even further:
wnew = liftA2 W `on` fallible
Great video, and the Haskell reference was the cherry on top.
Your channel has a bright future ahead and I will watch your success with great pleasure.
I actually didn't know what Infallible was for, this was definitely a good video!
Infallible is actually a workaround for the limitations of Rust syntax and type system when it comes to the ! never type. It is likely one of them will be made just alias for the other somewhere down the line.
@@KohuGaly Glad to see I'm not the only one who sees an issue with this. I find it bizarre to use a special type just to circumvent a problem that's fundamentally caused by forcing a function to return an error when it's not possible for that to happen.
Thiserror is a good choice for libraries, anyhow makes sense for applications. You shouldn't use anyhow in libraries (since it forces any applications using it to use anyhow too), but thiserror produces normal enums, it just saves boilerplate. You can use it for applications too, although some people prefer the ease and context capabilites of anyhow.
The advantage of anyhow is that you don't need to handle specific error cases, you can just say "oh whatever, when there's an error I'm just gonna print the error message to the screen" or something like that. On the other hand, if you actually do care about which specific error you get (say for example you want to recover from the error in different ways depending on what happened), then using enums / thiserr is the way to go! And for library code, probably very rarely want to use anyhow (and never want to have an anyhow::Result exposed from your API!).
5:32 I was going to bring up this exact point and then you said it. There have been tons of times where I've returned `Result` specifically because, to me, there is a semantic difference between "I have nothing to return to you" and "this operation *failed*."
If you don't have a need for an error type, then you should use an Option Imo. If there is a semantic difference between 'I have nothing to return to you' and 'This operation failed', return Result or if there are multiple ways to return fail specify an error. If there is only a single way by which the function does not return a value you should use an option.
That last line blew my mind! A result without an err is isomorphic to a bool. Pretty new to rust, but result and option seem a LOT better than doing "if data != null" checks in JS
I love your Rust videos so much! You're so so good at helping my mental model of things improve. Keep up the banger work!
These videos are incredible. It's so hard to find programming videos for any language that don't assume the viewer is a total noob to programming in general. I love this because, even though I'm already familiar with Option, Result, From, and all the other std library stuff, I didn't know about thiserror and anyhow. I just hope the rust community is a big enough audience to sustain this channel.
Coming to Rust from Haskell just wanted to say I appreciated the brief digression into what this would look like with do-notion in the Either monad. I really respect Rust's unified approach to using Result everywhere rather than exceptions. Got a lot out of your video, thanks.
I will chime in with the other comments.
You have found a great niche in the Rust educational landscape. Please continue exploring more and more tricky Rust concepts.
Thank you for your work !
I love the way you talk about hugely complex things in such a clean and clear, understandable way. One of the best rust channel on yt
You have a flavor of type theory / category theory when describing the isomorphisms of Result ~ Option and Result ~ T. I'm curious to watch your other videos if you would cover things such as dependent types, const N: usize, and what GATs map to in the realm of type theory. Thanks for the video!
One thing that drives me absolutely bonkers nuts is when libraries have custom error types that don't implement the Error trait. PLEASE if you are making a library implement the Error trait on your error types, without it being able to generically handle errors is literally impossible.
I usually just use std when I need something to handle the generic error.
Use thiserror
Small problem with implementing std::error::Error: Sometimes std does not exist. For libraries intended to be usable in low level environments where many of the functions of std don't even make sense, it's common to target core instead. Now, the Error trait is not one of those things that doesn't make sense in a low level context... which is why so many have wondered why it wasn't in core to begin with, and now it's _beginning_ to appear in core, but also nightly only.
@@angeldude101 In the meantime, what is the general rule for low level envs? I'm starting to do some embedded systems stuff with rust on a pi pico. Just panic?
Recently the error trait got moved into the core library, so hopefully this is easier now
I'm way too deep into this cult I mean programming language
ULTIMATE CRABIFICATION 🦀🦀🦀
People who claim that Rust is a cult, are in a cult.
This video finally fully cleared up the use of Result for me. Thank you!
Thanks Logan, great video. I'm currently working in another language and miss using Rust, and videos like these keep me fresh and up-to-date on the language.
This might be pedantic but it was fun to learn about: Never isn't exactly the bottom type. It is an empty type, with no values, but the RFC making it a full type explicitly says that it isn't the bottom type, because it's not a subtype of anything. It coerces to any type, but it isn't a subtype of anything. And this is awesome news for us: otherwise Vec would be a subtype of Vec for any T, and that means we wouldn't be able to write to a Vec.
Subtyping in Rust is pretty much limited to lifetimes, which is what seems to allow stuff like Vec to be covariant in rust even though it would have to be invariant in a language like Kotlin.
I have to confess I am always learning so much about Rust with all your videos!! The more I watch, the more I realise how wonderful and powerful Rust is as a programming language. Thank you so much!
The real gem in this video is as the derive_more crate.
The rest was great as well, but I felt at home with most of this. It’s nice to just hear it in detail and twist and turn concepts around an look at them from different direction. It really helps solidify the ideas.
Your Rust videos is a gem. Errors is a hot topic and extremely undervalued here on youtube. It should be covered more deeply. Errors in Rust is something that very much differs from other languages
Note that the compiler will correctly infer Vec for T in the Result if you just provide Result. You could simplify Ok(Self(v?)) even further with a `.map(Self)` instead :)
Your content is absolutely top-notch. Please keep making more.
You have one of the best Rust channels on youtube. Thanks so much for the clarity and quality of all your videos.
Your content is VERY helpful in reasoning about rust!
I shared your channel on 2 disc servers to potentially help others...and to give back to you for your hard work!
Keep it up, man
I WILL take what you present today as some added nuance for my existing understanding
Awesome video as always! It should be noted that Result also has a rich meaning - if this function returns, there has been an error. For example, a program that loops forever until some error occurs, like a server. Although, in this context, the name "Infallible" leaves a lot to be desired x)
you can do Result
@@PeterAuto1 Never type is my beloved, but unfortunately it's not in stable :,(
Wow this is exactly the kind of video I was hoping for. Thinking about Result as a generalization of Option is a really helpful mindset for thinking about the two types. Even if it's a little more nuanced than that, I think I get too hung up on the extra context that the "Ok" and "Err" names seem to provide. It always bothered me that it's accepted convention for Either to be used this way in Haskell, and I always thought it was just a chance for a "Right is right, lol" joke. But this video really clearly illustrated how helpful of a framework that is.
Maaan.. I've said this on a previous video of yours, but still the best rust content on YT!
I think what makes your videos great is that you actually explain the theory and logic behind the type system, so that what-s and why-s are a lot simpler to understand.
Your Rust videos remind me very much of Meyers' two Effective C++ books (which I devoured when they came out). I really look forward to more in this vein. Thank you.
Come for the rust, stay for the category theory! Good pace by the way 😊
Clicked on the rust, pleasantly surprised by the haskell!
I love watching your videos about Rust! So clean and elegantly explained, with personal remarks so that you're not like a robot. Amazing!
I just discovered your rust videos and I absolutely love them. Subbed and liked
Awesome video, as always!
You sir, are criminally undersubscribed.
One more channel, telling so much useful information about Rust! I'm all for it, thank you for your videos!
I saw this - and I thought: "WOW I NEEDED THIS I WISH I WAS SUBBED TO THIS BIG CHANNEL YEARS AGO". They I saw that I am subbed already.
Then I saw that your channel is one of those small channels which I felt needed 20 hours to binge. Then I saw the comment underneath which also says the same T_T
This channel will be huge. I'm calling it.
I am at 11:20. That blew my mind. Its SO crystal clear I actually had to pause.
The thing at 15:56 also blew my mind. What a video sheesh.
Great video about error handling with Result and Option. I even learned a few things new to me. Top notch content. Subscribed!
Thank you so much for putting this video together. It's very rare to see videos where programmers dive into the mental models of how to use features and patterns so that alone is incredibly helpful.
That aside, the relationship you've established between Result and Option makes a lot of sense, I was wondering if the difference between the two was just that in one of the them you can access an `Err` but this explanation made me understand the uses much better.
Hope you continue to make cool videos like these! 🙏
I am loving this in depth discussion of rust types and their usage. Keep up the good work!
Creating and dealing with errors in Rust has always been difficult for me. Thanks to you, I know understand them a lot better. I'll definitely look into the thiserror and anyhow crates.
Awesome video, I'm learning rust, I struggle a lot when working with results (how to unwrap, chain them...etc), videos like yours are very helpful. Thanks 🙏
What a FANTASTIC video! Thank you for putting this together. Loved the animation and color coding as you explain!
You should write a book about Rust. The way you are explaining it is simply amazing ❤
The best Rust videos on UA-cam. Amazing. Thank you so much for the videos and the time you take to make them.
Great video (an channel)! Very well explained. You use some great examples.
Came back to the video after reading some more Rust…makes more sense now. Appreciate making this for us.
That was really really good stuff. I’ve never used any of the error crates because I’ve always strived to handle/propagate errors before they hit main.
Some notes that I think would have been very beneficial (albeit philosophically) is that errors and the result/option enums are there to represent invalid state.
I think you are correct that None should be inferable, but the purpose of Err is to announce and detail what erroneous state has occurred. Take serde_json::Error the error is a enum but for relevant variants it contains line and column information. Great for syntax error but useless or EOF (empty json)
The last thing IMHO is that not all errors should be recoverable. For example if you are converting a &[u8] to a string and a non-UTF8 character is provided perhaps you can gracefully handle the error but if recovery is impossible then failure should be defined by the program.
Rust is a systems language an OS is not a guarantee. If failure is inevitable then provide relevant context before panic!(). I believe this is the reason why .unwrap and .expect panic on Err. How do you allocate E to T when the variable is expecting T. A case of UB for sure better to panic than let it hit memory
I really love these videos. The precision with which you approach analyzing how and why a piece of code does what it does, and in describing it, is something I have actually been looking for. Along with explaining computation theory with things like data structure isomorphisms, explaining side points like the Never type and the reasons for its existence... it feels like what you are going for is a combination of 'know your tools', with knowing the topic and the practical application. Impressed by how you combine these three.
Looking forward to seeing more. Definitely subscribing.
12:12 wow damn, thanks for the traversal tip, I did not know Rust has it🎉
It’s very useful in cases when you actually don’t need to accumulate all potential errors from the collection and just fail when first occurred
I watch this video every time I'm about to write a library to remind myself how to do it right, and every time I learn and remember a bit more. My journey of errors was Box, anyhow, thiserror, and I'm probably right in that most crustaceans go through this cycle lol. Great vid, thanks. Wish I had it when I started with rust.
Sooo good explained: Love how you peak into architectural misshapes everybody should take to their heart when writing return types. One writes for the usage, and being sloppy on return types and even returning too little sometimes just frustrates the users, so some extra thought is always welcome :) ❤
Great video! I'm new to Rust and this helped me out a lot with a toy project I'm working on where I was having issues chaining iterators and dealing with flip flopping between Options and Results. Looking forward to future Rust videos!
In the higher-level areas of my code, I like to separate errors (which now represent many processes) as being in two classes: recoverable and unrecoverable (which is a bit of a misnomer). Unrecoverable errors are when the code/program is missing some vital information, and, unless it's somehow fixed by something or that entire subsystem is reset, the program must fail. Recoverable errors are like I/O errors, where it's more like "This is a benign error that I can just try again at, but if it persists, then there might be a problem with the environment that the user should know about, which is why I'm telling you now."
I also prototype with anyhow::Error, I just use it blindly everywhere in a module as I design it. Once I've built up the design, I go in, look at all possible errors, and design my error types properly, rather than trying to guess what I think my API might look like when it's done.
I specifically do not represent an invalid program state in errors, as Rust makes invalid program states impossible. So if you wrote code that can have an invalid state, you're just writing buggy code and should remodel your design. Sometimes if you catch yourself writing an error, you can stop yourself to think "wait, do I really need to make this a runtime decision?"
One of the best channels about Rust lang
I subscribed only a short while ago and I see your subscriber count is climbing FAST. These are really good videos.
Great content, you explain it very clearly. Hope you continue with stuff like this
concise, easy to understand and straight to the point, you earned yourself a sub
brief note on 10:40 - the return type of a `return` expression has historically been a compiler magic version of unit, and in fact that’s one of the things that has been holding back the stabilisation of `!` as a language feature
Coming from Scala, I found this to be really helpful insight into errors in Rust.
Love the 3blue1brown animations! Great video, keep it up. You've just earned one subscriber btw 😊
These videos are so good!! Love the use of the Manim library
There is a really nice pattern that a Result can be used for even if it conveys the same amount of information as an option.
fn
Please keep that quality Rust content! Thanks for sharing!
Have I ever used Rust?: No.
Will I ever use Rust?: Probably not.
Do I know most of the things he is talking about?: Definitely not.
Did I enjoy the video?: Yes
These videos are always great explanations and I learn something new everytime.
A little note at the end - Result can be freely destructured as Ok(foo) is an irrefutable pattern (due to the Err variant being impossible to construct), and (at least IIRC) the optimiser (possibly as a result of NVO?) will unwrap the result at binary level in this case as well
Result probably has the same size/alignment/ABI as T, so unwrapping is just a no-op at the machine code level: rust.godbolt.org/z/bzssYq57T
@@_noisecode yes, that's one of the things I'm saying - the other is that you are allowed to do it by the rules of *Rust* as well (e.g. Ok(true) and Ok(false) are typically bit-compatible with true and false (as long as E is 1 byte or smaller, and fits into NVO), but you aren't allowed to destructure them freely if E is not !)
I see how the second part of my statement is confusing; I meant it is unwrapped _at all times_ - due, as you note, to the transparency of the ABI in this case
I appreciate that you styled your animations after 3Blue1Brown - maybe using his graphics library? - excellently put, super well documented on screen, and interesting. Keep them coming!
So clear and easy to follow. Great explanation, thank you!
Wow, I really appreciated how you stepped through these. Thank you!
Love the comparison to haskell! Haskell has many super cool and useful features.
I need more so glad I found your channel
These explanations are high quality stuff.
That is awesome! I learn more details about the mechanics behind Rust. And you have a very nice style.
I love the idea of having a safe program, but it really irritates me when I have a tree of functions that returns a result, and I have to set every single function to return a result. Maybe I'm just a bad at Rust though 😂
Great video on one of the more complex parts of Rust. Thanks so much!
Great tutorial, thank you. I second other comments: we would like more videos like this
This video was so good. Please, please create more videos. Thank you.
"You're thinking: If only we were writing Haskell, then we could use do-notation in the Either monad"
I understand this is a joke. I really do.
But damn, I was literally constructing a comment in my head about how neat this is in Haskell...
So the real joke was that for you, the joke wasn't a joke? I wonder what Haskell typeclass THAT is
Your rust videos are incredible 🎉
Your take is correct.
I hope your channel takes off even more! Awesome informative videos
Amazingly well done videos, can't wait for more!
This is more like Rust for Computer Science Students and I love it
Your explanations are great. Please keep up the good work!
this is what exactly I thought about about result and option by my intuition when I first gone through the rust docs, especially for the result enum as generalization, nevertheless great video, keep going.
Good Video, Keep up the good work. Really like to see more videos like this
I was uncompfortable with Result for some time because of the confusing builtin syntax around the type not the Result type itself. There are so many different way of interacting with them like unwrap and ? and OK() and all that. It took me some time to actually find a resource that packed all the different ways of interacting with Result in one place and when to use which one. The result type propagation of ? was particularly confusing at first because it seems like implicit magic if you don't know what you are looking at.
That was some time ago now though (4 years or so). So I assume the explanations of this are probably much easier to find and well written compared to back then.
This is absolutely fantastic.
These kind of more advanced but easily followed videos are incredibly valuable. Thank you so much, keep doing what you are doing!
anyhow rocks! I‘m using it in every project
Thanks for your content! ❤
Fantastic rust videos my dude 👍
10:33, OH SO THAT'S WHAT NEVER IS USED FOR!
I've had a trouble understanding, why would you even need a bottom type, but now I see.
makes sence.
Great video as always! I would love to hear you talking about manual v-table implementations. I know about two crates that use them internally (anyhow and bytes) and have some general idea of how it works, but I would love to hear an in-depth explanation of its tradeoffs, details, design patterns and maybe event unstable std APIs `std::ptr::{Pointee, DynMetadata}`.
Very useful information and excellent production.
another great high quality video
i dont think the none option should be used to indicate failure, instead i like to think of it as indicating that the value youre asking for does not exist. HashMap::get returns none when theres no value for the given key. i think using a result (even when theres only 1 possible kind of error) when theres a chance the function fails makes more sense and is more readable
You might like Gleam