3 ms·
> 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
by 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 agoI 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.