Algebraic Effects in Practice with Flix

This discussion on Hacker News revolves around the concept of effect systems in programming languages, with considerable debate about their practical application, design choices, and how they compare to existing programming paradigms.

The Promise and Academic Nature of Effect Systems

Several users acknowledge the theoretical elegance and potential benefits of effect systems, but also express concern that their academic origins lead to designs that are impractical or overly focused on theoretical purity at the expense of usability.

• artemonster expresses this sentiment strongly: "I really want effects to shine and thrive, but since this is a very academic topic, only academic people engage with the research and it comes with academic pedantism, perfectionist worldview, strange attraction to beautiful consistency, etc. This automatically places effect research FAR from any practicality and grounded realism."
• This academic focus is illustrated by artemonster's critique of debugging in effect systems: "Ever tried adding a simple print statement for debugging purposes while coding in effectful lang? compiler: 'NNNOOOOO!!!! THIS IS AN ERROR; I WILL NEVER COMPILE THIS NONSENSE YOU __MUST__ SPECIFY CONSOLE EFFECT WAAARGHH!11'"
• Another example of perceived academic overreach is the focus on "multi-resumable stacks." artemonster states, "how many times you really want to implement custom backtracking for multi resumable computations? this is such an obscure nonsensical use case that is hard to nearly impossible to solve efficiently, but everyone wants to support it. supporting this adds enormous complexity and kills any potential for performance. WHYYYYYYYYY."

Practicality vs. Theoretical Purity and Workarounds

A significant portion of the discussion centers on whether compromises for practical usability, like special handling for debug printing, are "workarounds" or necessary "pragmatic compromises."

• Warwolt offers a counterpoint to artemonster's debugging critique: "To be fair, presumably debug printig could be 'escaped' from the effect type checking if the designer of an effect system would want it. For instance, debug printig in Haskell completely sidesteps the need for the IO Monad and just prints in whatever context."
• artemonster dismisses this as a true solution: "yeah, most times its solved by side-stepping the strict type system and making an exception for debug prints. but this is not a real practical solution, this is a stupid workaround born from overinsistence on 'beautiful' design choices."
• thfuran questions artemonster's definition of a real solution: "It seems to me like a pragmatic compromise and very much a real solution. What would you consider a real solution that isn’t overinsisting on beautiful design choices?"
• artemonster proposes an "optional compiler pass" for the strong static type system, allowing developers to bypass it for immediate testing: "putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test."
• noelwelsh warns against such flexibility, linking it to performance degradation seen in languages like JavaScript: "This puts a lot of extra conditions on the runtime; you basically have to implement a 'dynamically typed' runtime like Javascript. In doing so you lose a lot of performance."
• Sharlin suggests a more nuanced approach for debugging, akin to Rust's Debug trait: "I’m sure default effects could handle this, just as Rust has some auto traits and default trait bounds. It doesn’t even have to be the full console i/o effect, it can be a specific debug effect that outputs to console in a dev build and to a file or devnull or whatever in release builds, or you could disable it in release builds and the compiler ensures there aren’t stray debug calls left, without needing a specific lint for that."

Comparison to Monads and Interfaces

Users draw parallels and distinctions between effect systems and established programming concepts like monads and object-oriented interfaces, particularly in how they manage side effects and program structure.

• mrkeen views effect systems as a continuation of the "what color is your function" problem, familiar from monads: "I currently use monads for my effects, and am open to the idea of language-based effects. But this isn't a solution to the colour problem - it _is_ the colour problem. The compiler stops you accidentally calling red from blue. If you want to do it deliberately, you change the caller from blue to red."
• voat finds algebraic effect handlers to be a simpler mental model than monads: "The algebraic effect handler pattern is a much simpler mental model than monads. And is transferrable to other languages pretty easily."
• epolanski asserts that effect data types are analogous to other monadic structures like arrays or options: "The effect data type admits an instance of monad, like arrays or option or result. Not sure why would you put those in competition, an effect is a supercharged ReaderResult."
• mrkeen expresses skepticism about bolting on effect systems, drawing a parallel to Java's Optional: "I am equally skeptical of bolting on effect systems after the fact. Even if one of these effect systems becomes 'the main one' and starts showing up in standard libraries, we'll still end up with declared-effectful code and undeclared-effectful code, but will again fall short of the goal, declared-effectful code."
• IshKebab echoes this, suggesting native support is crucial: "I agree, this seems like something where it really needs to be natively supported in the language from day one to work properly."
• vips7L queries how effects differ from interfaces: "Maybe I’m not getting it, but isn’t this just interfaces and implementations from the OO world? For example their movie one is: interface MovieApi { List<Movie> getPopularMovies(); }. What are effects providing over this?"
• abeppu clarifies that effects track "contextual requirements" beyond just what an interface specifies, enabling better testability and isolating effects: "So in java, you could write two distinct classes implementing the MovieApi interface as you defined it, one of which calls out to the web and one which doesn't, and nothing about the type indicates that difference. If you accidentally used the wrong class, your tests could make a network call and you might never notice, because you would not have tracked that effect."
• alethic elaborates on the interface comparison, highlighting key differences: "First, the implementation of an interface is static. It's known at compile time. For any given concrete type, there is at most one implementation of MovieApi. You're using the interface, then, to be generic over some number of concrete types, by way of only specifying what you need. Effect handlers can have _many_ implementations, actually." They also point out that effects can encompass "non-local control flow," unlike traditional interfaces.

State of Adoption and Implementations

The discussion touches upon languages that are implementing or experimenting with algebraic effects.

• ZeljkoS notes OCaml's experimental algebraic effects in version 5.0, referencing a tutorial and highlighting that they are "unchecked currently" and "A program that does not handle a performed effect fails with a runtime error."
• tanelso2 points to an updated OCaml effects tutorial link.
• vips7L references a TypeScript implementation: "See something like https://github.com/doeixd/effectively in Typescript."
• epolanski mentions Effect-TS as a more popular and robust TypeScript option: "There is a much more popular and robust implementation of effects for Typescript: https://effect.website/."
• artemonster initially mentioned Koka and Effekt as examples of effectful languages, with marvinborner providing a link to Effekt's interactive tour.
• Rusky points to ongoing academic work on exploiting single-resumability.

Minor Observations

• nkrisc points out a subtle display issue in a code example related to string interpolation in a dark theme.
• epolanski links to an interactive example within the effect-js project.