Wow Algebraic Effects are a totally new thing i never seen mentionned so far
I always thought that async /await was the best known way to handle resumable computation
Totally blew my mind
Effective Concurrency with Algebraic Effects in Multicore OCaml
31–40 of 63 posts
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#32I first encountered Algebraic Effects in Unison where they're called "abilities" [0] via the strangeloop talk from 2 years ago [1]. Just from the little I've seen of it I feel like AE is a fundamental abstraction tool that's been missing in programming language design. "Fundamental" as in the same level as function arguments. So many problems that were solved with myriad complex programming language constructs are just absorbed as a trivial user-implementation with an effect system: exceptions, sync vs async, dependency injection, cancellation tokens, dynamic contexts... all of these problems where the essential complexity is a need to have an effect that cuts through the function call stack.
I'm not saying that all our problems are solved and the programming world will now be rainbows and butterflies, I'm just saying that this feature is the correct framing and abstraction for issues we've run into many times in the past, and it has the potential to greatly simplify and unify the hacky, bespoke, situational solutions we've found.
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#33Earlier quoted context omitted.
In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.
This has nothing to do with the JVM. Scala for example is already capable of exactly what Erlang/Haskell do. This is merely about the language Java, which lacks support for to make such a programming style ergonomic. You either need a language with very powerful type-system or a dynamically typed language. (or specific support for it, like in Go, but even in Go you are limited to what the language designers forsaw) P…
Project Loom is both about the JVM and the language Java. Most of the work for Loom AFAICT is at the JVM level, and the benefits are that all Java code will Just Work(TM) with the new primitives underneath them at the end.
Scala’s varied async/concurrency libraries are implemented in user land, and still use threads underneath. Mechanically, you must opt in to these and have to work to interop with code that might use other primitives. Scala can handle a lot of this complexity at compile time w/ types, but it’s not perfect, and certain runtime behaviors will always be out of scope.
Loom improves this by allowing any language that runs on the JVM (Java, Scala, Clojure) to opaquely use virtual threads to run their existing synchronous, scheduler-unaware code on the new Loom concurrency primitives implemented in the JVM. That’s powerful!
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#34Earlier quoted context omitted.
In fairness to the JVM, the work on Project Loom would bring the JVM inline with what that document describes as the Erlang/Haskell "Hybrid threading" model.
In OpenJDK, Java threads are just thin wrappers around OS threads and OS threads are a very precious resource; a modern OS can't support more than a few thousand active threads at a time. I'm not sure how one would get there with the JVM's memory model. you'd need something like actors and a preemptive scheduler per core at the VM level with a share nothing state between actors/virtual threads. Erlang utilizes messag…
>In OpenJDK, Java threads are just thin wrappers around OS threads and OS threads are a very precious resource; a modern OS can't support more than a few thousand active threads at a time.
I don't know what you define as a few thousand active threads, but running the following C++ code let me run 70,000 threads before I got a resource error:
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#35Wow Algebraic Effects are a totally new thing i never seen mentionned so far I always thought that async /await was the best known way to handle resumable computation Totally blew my mind
For more mind-blowing stuff, try learning F#, where async/await as a language feature is something you could implement entirely in user-space (though of course you need to access the .NET APIs if you want to implement parallelism). F# has "computation expressions", which allow you to define syntax for fully-general "monad-like things", and the built-in `async` computation expression is just a part of the standard library and is defined using that mechanism.
I imagine exposure to algebraic-effects systems must make one feel the same way: like it's such an awful hack when a language has to have async support baked into its syntax!
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#36It would be handy to have a bit of explanation about what the term algebraic effect means.
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#37Is this what Dan talked about in react hooks origins? https://overreacted.io/algebraic-effects-for-the-rest-of-us/
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#38It would be handy to have a bit of explanation about what the term algebraic effect means.
You weren't the target audience of the post. But I found this helpful:
https://www.youtube.com/watch?v=hrBq8R_kxI0
As well as this post, which relates react hooks to algebraic effects.
https://overreacted.io/algebraic-effects-for-the-rest-of-us/
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#39> allowing the programmer to separate the expression of an effectful computation from its implementation
How does this compare with IO monads? Seems like they accomplish roughly the same goal
Re: Effective Concurrency with Algebraic Effects in Multicore OCaml
#40I've actually been playing with a similar idea in JavaScript, having pure functions generate "Plans" for async actions which are then executed later by other code. They can be thought of as Promises that haven't happened yet.
A neat side-effect (no pun intended) of doing things this way is that, unlike Promises, Plans can be stored as constants (or cached) and re-used multiple times.
I'm sure it's nowhere near as advanced or flexible as the OP, but it seems to be in the same general spirit