Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)

Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retro...

There are other cool stuff that is being worked on, which I am very excited about: https://discuss.ocaml.org/t/jane-street-compiler-development.... Hopefully, we will see many of these make it into OCaml 6.

Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature.

I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.

The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.

The type system for algebraic effects is still in the research and design phase at this point.

Right now, I am not even taking a guess of what will be the defining new major features of OCaml 6 (effect system + modular implicits maybe? Maybe not?).

Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.

As an Elixir (which steps on Erlang) and Rust dev I'm curious if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and Rust's tokio a run for their money in the parallel runtime space.

I'm super curious about OCaml, picked it up and left it several times in the last 3 years. Now that multicore is here I'll absolutely be picking it up again and try to use it for parallel scripting and for some of my work. Great job!

We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5...

The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 also has some http benchmarks

How does "bounding races in space and time" impact the generated machine code? Do you have some interesting examples of how it's different from the code C++ or JVM JIT would generate? What's the performance impact? Thanks!

See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf

Do you mean section 2 of the paper? It only contains C-like pseudo-code, no machine code.

The results section of the paper only compare the performance of Multicore OCaml with plain OCaml, not OCaml vs C++ / Java.

Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section discusses trade offs.

To summarise, atomic read and write in OCaml is more expensive than C++ since C++ SC atomics only establish total order between SC operations on not operations that are weaker but related to SC operations by happens before. We need stronger atomics for local data race freedom.

Our non atomic are also stronger than non atomics on C++ and Java. That said, The non atomic operations are free on X86 (compiled to plain loads and stores) and involve a lightweight fence before stores on weaker architectures such as ARM, Power and RISC-V. The performance results show that extra fences before stores have a barely noticeable impact on ARM and Power.