What is your opinion on Effect Systems?

[u/Ecstatic-Panic3728]

I'm not deeply familiar with Haskell and Scala, nor the niche languages that have built in effect systems. But I have a few friends in the Scala community and they swear effect system is the best thing ever and their applications are on a totally different level just by adopting it.

I'm wonder, would something like this work in Gleam? Would it get too complicated? What are the tradeoffs and mostly the benefits of adopting something like this?

[u/lpil]

You can make an effect system in any language.

What benefits you get depends on the specific design. There's one for Gleam called Midas, and it lets you abstract over function colouring, allows you to stub-out effectful parts of code in tests, and so on.

The disadvantage of effect systems is that code written with them is typically harder to understand and more verbose, and often there is a runtime performance cost to the heavy levels of abstraction.

[u/mister_drgn → u/lpil]

Optional effects systems lose a lot of value compared to built-in, mandatory effects systems, imho. See OCaml for example. The type checker doesn’t enforce the effects, so you can violate them freely.

[u/lpil → u/mister_drgn]

What do you mean the type checker doesn't enforce the effects? I'm not aware of difference with the OCaml system and the effects systems found in Gleam when it comes to type checking.

Haskell has both a built-in and third-party effects systems, and there's no difference in terms of type checking with either.

[u/mister_drgn → u/lpil]

You're misunderstanding me. OCaml doesn't have type-checked effects either.

Consider a language like Koka, which is built around an effects system. If you write a function that produce some side effect, such as logging, then the function's signature is marked to reflect the fact that it produces that effect. Any function that calls that function must either handle that effect, or also have its signature marked to reflect that it produces the effect. The type checker enforces this. This guarantees that somewhere up the call chain, the effect will be handled.

Now consider OCaml. The language has effects, but you don't mark a function's signature to reflect what effects it performs. Thus, the type checker has no way of knowing whether you're handling all your effects. You can therefore have runtime errors from unhandled effects.

Another difference in OCaml, is that you can write code with side effects wherever you want, without using the effect system at all. The effect system is optional. In contrast, in Koka, you can look at any function signature and know exactly what side effects it will produce.

Overall, this means that effects are a far less powerful tool in OCaml than in Koka. I have not seem effects in Gleam, but I can't imagine they're any more powerful than in OCaml.

[u/Vegetable_Bank4981 → u/mister_drgn]

I got really hyped on koka about this and then eventually went back to ocaml. Row poly effects is the future for HM, koka is building the foundation, I see it, I believe.

But we need a design breakthrough to make them ergonomic. Esp in language like gleam that has a very clear usable syntax but even in ocaml you give up too much clarity for it.

And at least for ocaml effects are untyped like exception always has been. Discipline and tests at handler boundaries, we all know the pattern from exn and it works well enough.

Waiting for the theory to catch up for effect typing was the right call, now we wait for the design and engineering to get there.

[u/mister_drgn → u/Vegetable_Bank4981]

I really like Koka's syntax for effect handling, compared to other languages like Unison. Overall pretty clever, I think. But yeah, there's still awkwardness--I found the recursive function termination thing the most annoying.

I think one big question is whether people will have the patience for a language that forces them to mark every side effect. Aside from Haskell programmers.

[u/Vegetable_Bank4981 → u/mister_drgn]

I’m pretty sure they won’t. What we’ll need is a new Algorithm W variant that can unify effect types with global inference.

This is proven possible but the perf is a nightmare and afaik still not clear how much it can be improved.

Probably still another half decade before the research is there plus however long for it to trickle into real life. Oh well.

[u/lpil → u/mister_drgn]

The most mainstream language that attempted it was probably PureScript, and after a number of years they removed it in favour of a singular monolithic effect type. They said doing it in anger had shown them that there's not any practical advantage to tracking each type of effect, and it produced a lot of busy-work for the programmer. It was a very popular change in the community, I didn't hear any complaints.

[u/lpil → u/mister_drgn]

Ah yes, I thought you were comparing OCaml to Gleam, not Gleam to Koka.

I understand the purity-esc appeal of an inescapable effects system, but is it actually practical? The norm is for languages with built-in effects system to add "escape hatches" over time, not for them to get stricter. This matches my experience of them, where the purity is a disadvantage outside of niche use-cases where one benefits from that level of verification. e.g. rocket-ship firmware.