Maybe it was already asked before but what are benefits of Bluefin compared to using plain IO functions? Why should I use foo :: (e1 :> es, e2 :> es) => Handle1 e1 -> Handle2 e2 -> Eff es Foo instead of a plain foo :: Handle1 -> Handle2 -> IO Foo

I see a lot of speculation here and people speaking past each-other. Why don’t you all go and build something with an effect system, and come back with actual production insights? The conversation would certainly be more productive.

Why don’t you all go and build something with an effect system, and come back with actual production insights? I think I’ve heard this before…yes, that’s what it was: …can we just wait until the GHC developers choose one, so it can be deemed as recommended workable?

The second one is tightly coupled to the effect system. It’s impossible to convert to a pure IO action and pass to a non-Eff subsystem … It’s only reusable within Eff framework and unusable outside. Doesn’t look too modular. This is not true. There is no coupling to the effect system (assuming we…

[image] vshabanov: Agreed. The more pure code and the less IO the better. If one wants better control, it should be a discreet decision, not a jump on a bandwagon. That’s good news for effectful and Bluefin then, because you can use them in internal components without effecting external APIs…

[image] vshabanov: It’s only reusable within Eff framework and unusable outside. I agree, but not everything has to be reusable outside the context it is important in. I mentioned codebase, but that is not good enough. I’d draw a distinction between application/library code. Then I’d agree th…

Because I also can’t remember everything: [image] The issues with effect systems Learn Hello, I’ve been rather interested in effect systems for months at this point and I’ve been researching their benefits and issues. I do know that their benefits include: Potentially b…

As someone who doesn’t have a strong opinion on this topic I’d say ultimately it depends on the kind of applications that you write and on personal preference. However I’d like to point out another aspect, that I don’t see mentioned in this discussion, namely that Haskell is not a “batteries-includ…

[image] BurningWitness: In my view the only true benefit to effect systems is that it’s the only sane way of getting … a mirror test system that behaves exactly the same, but calls test versions of all real-world things it links to. There are many ways to achieve mocking without effect system…

[image] vshabanov: There are many ways to achieve mocking without effect systems Production services with test data is QA territory; Built-in mocking means your declarations and implementations for both the production and the test versions have to live in the same module, whereas they mo…

[image] atravers: Then here’s the challenge for you and everyone else who thinks IO a is now bunglesome and needs diluting: type IO a = Eff All a …use your preferred system of effects to provide a Haskell declaration for All . I think I finally understood this concern. Effect systems (those…

Why use an effect system?

Learn

atravers November 30, 2024, 10:43am 67

Because I also can’t remember everything:

…to avoid further gratuitous repetition here.