4 ms·

Rust genuinely will stop you, though. You can't take a Result<T> and get an Ok(T) out of it unless there's no error; if it's an Err then you can't continue as i

Rust genuinely will stop you, though. You can't take a Result<T> and get an Ok(T) out of it unless there's no error; if it's an Err then you can't continue as if you have a T. It doesn't force you to do something productive with the error, but you can't act like it was what you wanted instead of an error.

TheDong 2y ago
Yeah, but now you have to teach your programmers about generics and applicative functors. I'm just a simple country gopher, but my brain isn't capable of understanding either of those things, nor are any of my coworkers, nor any of the people we hire, and it doesn't really matter how theoretically "nice" and "pure" your generics and results and monads are if us real professional programmers get confused by them. Errors need to be explicit values, not magic monads. 'if err != nil' is good and easy to think about, 'res.map().or_else()' is incomprehensible line noise no normal programmer can understand. https://paulgraham.com/avg.html#:~:text=The%20Blub%20Paradox https://paulgraham.com/avg.html#:~:text=The%20Blub%20Paradox
- amenhotep 2y ago
  I think you have ideas about these types that make them seem overcomplicated! Either that, or I'm way smarter than the average programmer and really am massively wasting my talent :) but if you ask me the first is much more likely. I'm awed by the clever things people post about on here and am still not 100% sure I understand what a monad even is, but Result and Option seemed very easy to pick up. The one liner functor stuff in particular I think is a big distraction. To me the basic building block is the match statement - you match on a result, if it's Ok(T) then you get to do something with T, and if it's Err(e) then you get to do something with e. At that level it's very simple. And as far as I know (no expert though) any clever expression can be decomposed into a series of nested and possibly repetitive match statements, the apparent magic is illusory. But I do hear you and I get the appeal of Go from that angle, obviously sticking with what you like is a good idea. Just saying Rust isn't that bad :)

TheDong 2y ago

Yeah, but now you have to teach your programmers about generics and applicative functors. I'm just a simple country gopher, but my brain isn't capable of understanding either of those things, nor are any of my coworkers, nor any of the people we hire, and it doesn't really matter how theoretically "nice" and "pure" your generics and results and monads are if us real professional programmers get confused by them. Errors need to be explicit values, not magic monads. 'if err != nil' is good and easy to think about, 'res.map().or_else()' is incomprehensible line noise no normal programmer can understand. https://paulgraham.com/avg.html#:~:text=The%20Blub%20Paradox https://paulgraham.com/avg.html#:~:text=The%20Blub%20Paradox

amenhotep 2y ago
I think you have ideas about these types that make them seem overcomplicated! Either that, or I'm way smarter than the average programmer and really am massively wasting my talent :) but if you ask me the first is much more likely. I'm awed by the clever things people post about on here and am still not 100% sure I understand what a monad even is, but Result and Option seemed very easy to pick up. The one liner functor stuff in particular I think is a big distraction. To me the basic building block is the match statement - you match on a result, if it's Ok(T) then you get to do something with T, and if it's Err(e) then you get to do something with e. At that level it's very simple. And as far as I know (no expert though) any clever expression can be decomposed into a series of nested and possibly repetitive match statements, the apparent magic is illusory. But I do hear you and I get the appeal of Go from that angle, obviously sticking with what you like is a good idea. Just saying Rust isn't that bad :)