3 ms·

> I think it's fallen out of favor, but I always preferred the "Either" monad style of error handling. I think the cool kids call it "railway oriented programmi

> I think it's fallen out of favor, but I always preferred the "Either" monad style of error handling. I think the cool kids call it "railway oriented programming" but I never liked that term. Regardless, it's not radically different than the Go style, just instead of returning back two things and checking for `nil`, it's wrapped up into an algebraic data type. Is that falling out of style? Sounds like Rust's Result type, but i'm unfamiliar with monads/etc. If it is similar, i spent ~5 years in Go and have now had about equal time in Rust - i vastly prefer those algebraic types for errors. Notably because it _can_ be as simple as Go's string concat behavior, but it can also be far more expressive. Yes, Go's type can also be more expressive by adding interfaces/etc, but it's difficult to beat a good enum in my experience. At risk of sounding Rust biased, proper Enums are something that would have made Go more elegant imo. Unlike Generics/etc which are a contentious topic (or used to be, at least), proper enums are just so damn handy and cost so little. My 2c.

tombert 3y ago
> Is that falling out of style? I'm a bit outta the loop in the pure FP world now, because I've been stuck doing Java and C# for the last 5 or so years, but I think that world is trying to move to an algebraic effects-style system. People keep trying to explain to me why that's "better" but I'm not really sold on it, because it just feels like we're reinventing goto, though generally when I have contrary opinions like that it turns out that I'm wrong. I don't really know Rust very well, but I suspect it has a similar way of doing `map` and `bind` to handle downstream stuff, since it has functional roots. The biggest issue I ever had with it in F# is the fact that they don't really have a concept of a monad transformer and therefore you can't easily combine monads, so if you have to mix `async` and the `Choice` monads (more or less F#'s version of Either), you have to explicitly craft your own custom monad. It's really not that bad but it's less sexy than proper monad transformers. Algebraic data types are so utterly useful that I get annoyed that it's not standard in every language.
- tonlage 3y ago
  I think it's only academic FP that's currently interested in effect systems. most production FP still use the traditional monad error handling. Rust's `Result` type does indeed have a `.map()` function, which works how you'd expect (and `Result`is an iterator, which give syntax for it). Yeah, algebraic data types are very nice, and feel like such a free lunch. I cry every time i have to implement something that should have been a one-line sumtype definition as a class hierarchy.

tombert 3y ago

> Is that falling out of style? I'm a bit outta the loop in the pure FP world now, because I've been stuck doing Java and C# for the last 5 or so years, but I think that world is trying to move to an algebraic effects-style system. People keep trying to explain to me why that's "better" but I'm not really sold on it, because it just feels like we're reinventing goto, though generally when I have contrary opinions like that it turns out that I'm wrong. I don't really know Rust very well, but I suspect it has a similar way of doing `map` and `bind` to handle downstream stuff, since it has functional roots. The biggest issue I ever had with it in F# is the fact that they don't really have a concept of a monad transformer and therefore you can't easily combine monads, so if you have to mix `async` and the `Choice` monads (more or less F#'s version of Either), you have to explicitly craft your own custom monad. It's really not that bad but it's less sexy than proper monad transformers. Algebraic data types are so utterly useful that I get annoyed that it's not standard in every language.

tonlage 3y ago
I think it's only academic FP that's currently interested in effect systems. most production FP still use the traditional monad error handling. Rust's `Result` type does indeed have a `.map()` function, which works how you'd expect (and `Result`is an iterator, which give syntax for it). Yeah, algebraic data types are very nice, and feel like such a free lunch. I cry every time i have to implement something that should have been a one-line sumtype definition as a class hierarchy.