A nice detail: this video is hosted on the new OCaml website (https://v3.ocaml.org/en), which includes its own peertube instance.

Also interesting: the new OCaml website is built with ReScript, the rebranding of ReasonML.

That's right. Here's the forum post presenting the new websites and the choices made: https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocaml....

What's the OCaml community's perception on when multicore will fully land in trunk?

My understanding is that 4.14 is scheduled for Q1 2022 and 5.0 with multicore _might_ be released roughly in parallel.

Are there any benchmarks? Comparisons to other multicore runtimes, like GoLang's?

I remember seeing a graph where http/af, a http server, was close to Go net/http. I'll try to run https://github.com/ocaml-multicore/retro-httpaf-bench and report back. I also found another graph, but I'm too colorblind to read it properly https://user-images.githubusercontent.com/554131/131155247-f....

Edit: the benchmark fails to build

Top two lines are httpaf_eio and rust_hyper.

Next two lines are httpaf_effects and httpaf_lwt.

Bottom two lines are nethttp_go and cohttp_lwt_unix.

All in order from top to bottom.

Thank you very much!

Yeah the colors are really not great for color blind people, I rather have some symbols or similar on them

That's one of the small things I like about more complex charts (more complex than a picture): I can usually hover over the chart to see the label.

We don't compare against Go pervasively. Benchmarking across languages is hard generally, but here is a result on a specific benchmark comparing several versions of OCaml benchmarks against Go and Rust on a Http server benchmark: https://github.com/ocaml-multicore/retro-httpaf-bench/pull/1....

If there are suggestions to make the Go and Rust versions, please feel free to tell us how in the issue tracker.

Our paper from ICFP last year has extensive benchmarks against stock OCaml: https://arxiv.org/abs/2004.11663

In short there should be very little performance difference against stock.

As KC has linked in a sibling comment there's a project going to explore using effects to write high performance IO libraries and that has some early benchmarks.

Yes, check out https://watch.ocaml.org/videos/watch/playlist/7a4ad26a-b8c5-... for some interesting comparisons.

Metayears?

> And still, time and again, languages are being designed with these concerns as an afterthought.

Is that still happening? My impression is that any languages designed since multicore became common have thought very hard about their approach. The problem we have is that a lot of our languages have been around a while. Even Python is 30 years old at this point!

Erlang here is the miracle to me. Its programming model was designed for concurrency on a single core, but when SMP processers appeared all it needed was a VM change that was completely transparent to the programs above it and suddenly all Erlang programs were extremely parallel!

Erlang was not designed for concurrency on a single core, it was designed for parallelism on multiple machines. Because of this, erlang processes do not share memory and SMP-level parallelism was easy to add.

Many languages side step the problem. With JS-inspired languages like Dart, you are limited to message passing workers. Many high performance concurrency applications are difficult without shared memory support.