5 ms·

Isn't Java capable of the same thing now that it has algebraic data types with records + sealed classes + pattern matching? Given that Java already has a fine c

Isn't Java capable of the same thing now that it has algebraic data types with records + sealed classes + pattern matching? Given that Java already has a fine concurrency story, isn't OCaml a hard sell to someone that's not into compiler development to depend on its rich ecosystem?

wtetzner 5y ago
Algebraic data types are not the same as an algebraic effects system.
- johnnycerberus 5y ago
  Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from university failing me now.
  - deleted 5y ago
    [deleted]
  - octachron 5y ago
    You cannot resume a computation with exceptions. At most, exceptions are a subset of effects. Similarly, a lot of the issues with checked exceptions in Java come from the lack of exception polymorphism in the checked exception type system. Adding the two points, you cannot really call checked exceptions an effect system.
    - nsonha 5y ago
      not to mention that exceptions as flow control is frowned upon in java, so while there are similarities, they are different in designation.
  - shwestrick 5y ago
    The defining feature of these effect systems is "resumable continuations". Essentially, at the point where you catch an exception, you have the option of resuming the code which threw the exception, and you can tell it how to proceed. So, whereas exceptions only jump backwards in the stack, resuming a continuation sorta lets you jump forwards again, back to where you were. It's really powerful stuff.
kjaer 5y ago
Though they share the word "algebraic", algebraic data types != algebraic effects. And while Java has good support for concurrency primitives and concurrent data structures, it does suffer from the problem highlighted in the article: > Over time, the runtime system itself tends to become a complex, monolithic piece of software, with extensive use of locks, condition variables, timers, thread pools, and other arcana. I'm not an expert on this, but my understanding is that the problem that algebraic effects tries to solve is to improve language semantics to make it easier to separate different levels of abstraction (e.g. separating the what from the how), while also encoding the performed effects into the type system.
weatherlight 5y ago
Compared to Erlang, Haskell, an other FP languages, Java's concurrency story leaves a lot to be desired. https://medium.com/traveloka-engineering/cooperative-vs-preemptive-a-quest-to-maximize-concurrency-power-3b10c5a920fe https://medium.com/traveloka-engineering/cooperative-vs-pree...
- papercrane 5y ago
  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.
  - weatherlight 5y ago
    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 message passing and immutability to do this.
    - Kranar 5y ago
      >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: https://godbolt.org/z/74GsY1Kds https://godbolt.org/z/74GsY1Kds
      - weatherlight 5y ago
        Erlang processes are not OS processes. They are implemented by the Erlang VM using a lightweight cooperative threading model (preemptive at the Erlang level, but under the control of a cooperatively scheduled runtime). This means that it is much cheaper to switch context, because they only switch at known, controlled points and therefore don't have to save the entire CPU state (normal, SSE and FPU registers, address space mapping, etc.). Erlang processes use dynamically allocated stacks, which start very small and grow as necessary. This permits the spawning of many hundreds of thousands — even millions — of Erlang processes without sucking up all available RAM. Erlang used to be single-threaded, meaning that there was no requirement to ensure thread-safety between processes. It now supports SMP, but the interaction between Erlang processes on the same scheduler/core is still very lightweight (there are separate run queues per core).

wtetzner 5y ago

Algebraic data types are not the same as an algebraic effects system.

johnnycerberus 5y ago
Java's checked exceptions can be considered an effect system and coupled with ADTs I suppose we can call it an algebraic effects system. I mean the domino effect in which the exception has to be handled in each method that calls that is what seems to me the effect/handler counterpart that is present in Java. In the end an algebraic effect is just an extension of a type system that supports ADT, or is my memory from university failing me now.
- deleted 5y ago
  [deleted]
- octachron 5y ago
  You cannot resume a computation with exceptions. At most, exceptions are a subset of effects. Similarly, a lot of the issues with checked exceptions in Java come from the lack of exception polymorphism in the checked exception type system. Adding the two points, you cannot really call checked exceptions an effect system.
  - nsonha 5y ago
    not to mention that exceptions as flow control is frowned upon in java, so while there are similarities, they are different in designation.
- shwestrick 5y ago
  The defining feature of these effect systems is "resumable continuations". Essentially, at the point where you catch an exception, you have the option of resuming the code which threw the exception, and you can tell it how to proceed. So, whereas exceptions only jump backwards in the stack, resuming a continuation sorta lets you jump forwards again, back to where you were. It's really powerful stuff.

kjaer 5y ago

Though they share the word "algebraic", algebraic data types != algebraic effects. And while Java has good support for concurrency primitives and concurrent data structures, it does suffer from the problem highlighted in the article: > Over time, the runtime system itself tends to become a complex, monolithic piece of software, with extensive use of locks, condition variables, timers, thread pools, and other arcana. I'm not an expert on this, but my understanding is that the problem that algebraic effects tries to solve is to improve language semantics to make it easier to separate different levels of abstraction (e.g. separating the what from the how), while also encoding the performed effects into the type system.

weatherlight 5y ago

Compared to Erlang, Haskell, an other FP languages, Java's concurrency story leaves a lot to be desired. https://medium.com/traveloka-engineering/cooperative-vs-preemptive-a-quest-to-maximize-concurrency-power-3b10c5a920fe https://medium.com/traveloka-engineering/cooperative-vs-pree...

papercrane 5y ago
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.
- weatherlight 5y ago
  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 message passing and immutability to do this.
  - Kranar 5y ago
    >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: https://godbolt.org/z/74GsY1Kds https://godbolt.org/z/74GsY1Kds
    - weatherlight 5y ago
      Erlang processes are not OS processes. They are implemented by the Erlang VM using a lightweight cooperative threading model (preemptive at the Erlang level, but under the control of a cooperatively scheduled runtime). This means that it is much cheaper to switch context, because they only switch at known, controlled points and therefore don't have to save the entire CPU state (normal, SSE and FPU registers, address space mapping, etc.). Erlang processes use dynamically allocated stacks, which start very small and grow as necessary. This permits the spawning of many hundreds of thousands — even millions — of Erlang processes without sucking up all available RAM. Erlang used to be single-threaded, meaning that there was no requirement to ensure thread-safety between processes. It now supports SMP, but the interaction between Erlang processes on the same scheduler/core is still very lightweight (there are separate run queues per core).