HOLY BEAUTIFUL
>>107624959fucking disgusting
>>107624959I'll take that over C++ https://www.youtube.com/watch?v=7fGB-hjc2Gc
>>107624959actually you aren't supposed to use Option<T> everywhere. it is horribly written, I refuse to believe that it wasn't possible to get rid of at least some of them
>>107624959>SomeFuck that.>>107625189https://www.youtube.com/watch?v=YR5WdGrpoug
>>107625196>https://www.youtube.com/watch?v=YR5WdGrpougI ain't watching a 1 hour video as an answer on a two sentence post
>>107625189it's okay that get_user() returns a Some<User> but everything inside the user should just have default values set and not be nullable
>>107625250yes, that's what I'm talking about. you should make bad states irrepresentable when it's possible. using Option where it's not needed is like using a signed integer to represent an inherently unsigned value
>>107624959Why not use constructors/From instead of nested literals like this?You could even just 4 let statements to reduce lines or code and clutter.
>>107625227Rich Hickey is fantastic. Basically he's again Optional<> fanatism.
>>107625330Oh, this is match, not a builder.Use ? then.
>>107625338>Basically he's again Optional<> fanatism.well, Option<> is just a tool. sometimes having an entire error type for a proper Result<> is redundant, that's when you are supposed to use it. but it really seems like sometimes people just use it everywhere and at the end you have to make tons of unnecessary checks. generally, I'd say that the general idea from this https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ article applies here (even though it's about haskell)
