This is an abuse of this term, which refers to immutable transformations that reuse memory, as in Roc and Koka, not to hiding effects within a function.
> It's the code you would write in Python with types you get from OCaml and no monads.
It's also the code you could write in OCaml itself.
---
Having used OCaml 5 effects, I'm convinced that the trend of globally scoped effect constructors, dynamically scoped handlers and effect-typed functions are the wrong approach. They couple too many orthogonal features.
Handlers should be consumed as (records of) functions that can't leak from their scope (see 'local' in OxCaml, 'ref struct' in C#) and are passed down as a capability. Now you're using two more general mechanisms to express your effects, and other forms of dynamic scoping or dynamic dispatch can be made orthogonal to effects themselves.
this is a really nice looking language! the central focus on using effects to get zero cost abstractions is a very attractive one; I really hope the language makes it out of the experimental toy compiler stage.
I feel the author’s pain. LLMs take over right as we’re finally figuring out the unifying models and algorithms for programming languages.
Some time back I went on a tour of the fort at Dry Tortugas. Largest brick masonry fort in the world. Many innovations of the form. It was abandoned right as it was completed because barrel rifling had just been invented, dramatically increasing the penetrating power of artillery, rendering brick masonry forts obsolete virtually overnight.
Make better typed programming languages should improve agentic ergonomics as well as human ergonomics. I’d expect better performance by the agents if they can encode more constraints in the type system like this.
Effects allow more aspects of computation to be represented/generalized, but as the author has noted concrete implementations have already been tried in some cases. Rust’s ownership, Java’s exceptions, Typescript’s async are all instances where the language made a choice about and provided syntax for some effect.
Generalized effects are not yet proven (IMO) to improve developer ergonomics for rank-and-file devs. It may be the case that most devs need most decisions to be made for them, and the power of effects is just lost to them. That may also apply to agents. They don’t _need_ to encode the constraint. The constraint was decided when the language was picked.
i love that effect based languages are getting more popular but how long will it take until one of them moves from unfinished experimental to at least beta?
verse is already used in production but its missing basic features like unions and lambdas, the compiler and runtime are closed source, and its tightly coupled to fortnite but also badly integrated with it at the same time.
koka is way more mature but i couldnt find a single project using it thats more than a demo or personal "lets try a new language" type thing. its explicitly a research language and not going awawy from that any time soon.
Is it just me or do the first few examples seem worse than doing the same things without effects?
I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)
If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)
And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.
> It's functional but in place
This is an abuse of this term, which refers to immutable transformations that reuse memory, as in Roc and Koka, not to hiding effects within a function.
> It's the code you would write in Python with types you get from OCaml and no monads.
It's also the code you could write in OCaml itself.
---
Having used OCaml 5 effects, I'm convinced that the trend of globally scoped effect constructors, dynamically scoped handlers and effect-typed functions are the wrong approach. They couple too many orthogonal features.
Handlers should be consumed as (records of) functions that can't leak from their scope (see 'local' in OxCaml, 'ref struct' in C#) and are passed down as a capability. Now you're using two more general mechanisms to express your effects, and other forms of dynamic scoping or dynamic dispatch can be made orthogonal to effects themselves.
this is a really nice looking language! the central focus on using effects to get zero cost abstractions is a very attractive one; I really hope the language makes it out of the experimental toy compiler stage.
I feel the author’s pain. LLMs take over right as we’re finally figuring out the unifying models and algorithms for programming languages.
Some time back I went on a tour of the fort at Dry Tortugas. Largest brick masonry fort in the world. Many innovations of the form. It was abandoned right as it was completed because barrel rifling had just been invented, dramatically increasing the penetrating power of artillery, rendering brick masonry forts obsolete virtually overnight.
This project evokes a similar feeling.
Make better typed programming languages should improve agentic ergonomics as well as human ergonomics. I’d expect better performance by the agents if they can encode more constraints in the type system like this.
It’s possible.
Effects allow more aspects of computation to be represented/generalized, but as the author has noted concrete implementations have already been tried in some cases. Rust’s ownership, Java’s exceptions, Typescript’s async are all instances where the language made a choice about and provided syntax for some effect.
Generalized effects are not yet proven (IMO) to improve developer ergonomics for rank-and-file devs. It may be the case that most devs need most decisions to be made for them, and the power of effects is just lost to them. That may also apply to agents. They don’t _need_ to encode the constraint. The constraint was decided when the language was picked.
i love that effect based languages are getting more popular but how long will it take until one of them moves from unfinished experimental to at least beta?
verse is already used in production but its missing basic features like unions and lambdas, the compiler and runtime are closed source, and its tightly coupled to fortnite but also badly integrated with it at the same time.
koka is way more mature but i couldnt find a single project using it thats more than a demo or personal "lets try a new language" type thing. its explicitly a research language and not going awawy from that any time soon.
For a second I thought the syntax was Koka, which is also a language with effects. But it's not, there are some syntax differences later in the post.
Is it just me or do the first few examples seem worse than doing the same things without effects?
I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)
If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)
And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.
This sounds pretty cool. The author appears to be Claude.
I highly doubt the author is Claude, and would encourage you to read the last paragraph of the article.
The author has clearly put a lot of love and labour into this work.
How can you tell?
This is getting ridiculous. Maybe this comment is Claude, too.
OP is a credible poster so I was indeed curious as to why he wrote that. As for my comments -- em dash em dash -- they are entirely by moi.