Not dumb questions at all.

Multicore adds parallelism via Domains (which are essentially heavyweight threads) and concurrency via Effects and fibers. There's a multicore GC that supports both of those.

We plan to upstream things in two parts. First domains-only parallelism and then effects as a follow-up. When the latter lands users will be able to define their own effects and handlers, yes.

Performance is pretty good, you can see our PLDI2021 paper for a proper performance evaluation and loads more details: https://arxiv.org/abs/2104.00250

Good questions!

1) As I mentioned in https://news.ycombinator.com/item?id=27142502 there is support for parallelism and concurrency.

Giving an example of where these might be useful in a webservice.

The addition of shared-memory parallelism is beneficial where you might have a great deal of shared state that needs to be used to service requests. An in-memory cache is a good example - with a processed-based approach managing read/writes and avoiding significant overhead from marshalling the data is difficult.

Concurrency via effects at a minimum can make writing network-based services much more pleasant (and debuggable!). See the examples in https://arxiv.org/abs/2104.00250 where programs can be written in a direct-style similar to blocking IO but using effects are transformed to use asynchronous interfaces. There's work going on in the project at the moment to build fast cross-platform IO implementations that sit atop of uring/gcd/iocp.

3) This is a good question and one we're still working on. I think one of the lead developers KC has a few good ideas about instrumentation we can do to enable detecting races to global state. It's certainly going to be an issue for people porting large codebases.

4) This is the place to start: https://github.com/ocaml-multicore/multicore-opam#install-mu... .

OCaml (or its immediate predecessor[1]) had a multicore implementation, but it was dropped because of its complexity and effect on single-thread performance. The challenge is to add it back in a way that is maintainable and doesn't negatively affect current users.

[1] https://www.researchgate.net/publication/2774662_Concurrent_...

As the sibling comment mentions, the hard part is actually retrofitting multicore whilst maintaining compatibility _and_ performance.

Our paper last year covers most of why this is tricky: https://arxiv.org/abs/2004.11663

Abandoned is perhaps too strong a term :-). Effect handlers in the language are supported by fibers, lightweight stacklets managed by the runtime. The details of the implementation can be found in the upcoming research paper in PLDI'21 conference [1]. The effect handlers in Multicore OCaml today do not provide effect safety. Programs are not statically guaranteed to handle all the effects they may perform. This is only as bad as exceptions in OCaml and every other mainstream language with exceptions.

We are working on developing an effect system, which will ensure effect safety i.e, the compiler ensures that all the effects performed are caught. You also get a nice inferred type that says what effects a particular function may perform; if it performs none, then it is a pure function! This implementation would still use the current fiber support in the runtime. Leo White, one of the developers of Multicore OCaml had given a talk on this new effect system a few years ago [2]. That's the best place today to learn about the new effect handlers.

The plan is to first add the fiber runtime support to OCaml without the syntax extensions for effect handlers, and then introduce syntax along with the effect system.

[1] https://arxiv.org/abs/2104.00250

[2] https://www.janestreet.com/tech-talks/effective-programming/

It depends? It's easy in Ocaml to fork child processes, set up pipes, and pass messages back and forth. There are libraries that paper over the details (or you can roll your own, as I suspect many of us have done over the years).

That approach is not suitable for every workload, but fine for most map/reduce applications.

Often, it's just about finding a stick. They don't want to use OCaml and the absence of multi-core features gives them the excuse they were looking for. Now they can inform management: "OCaml is not an option. we'll stick with <insert PL here>"

Yeah I really don't know because OCaml already has async constructs. It doesn't seem like it should be a dealbreaker for most. That being said, it has a reputation for being extremely performant so it might just be that people feel like it's so close to being usable in a lot of situations it currently isn't so there is more aggregate desire to allow for multicore execution

Forking new processes is less efficient than spawning new threads as processes uses more machine resources and more memory. In addition, communication between threads is far more simple than communication between processes. Multicore may not be deal-breaker for server applications, but it matters for applications that require parallel processing.

> We have prototyped offloading CPU intensive computations in Lwt programs using Multicore OCaml

This is very interesting! I'm wondering if you are aware of any discussions with the async maintainers about what their plans are with the multicore runtime?

thx! Another question. Suppose you're starting from scratch, is it worth going the effects based async io route ? https://github.com/kayceesrk/ocaml-aeio seems very interesting...

Also no unicode support which is a huge con.

> It has some nice things like automatic type inference so you don't have to write very many type annotations.

I'm not quite sure what you're going for here. The Hindley-Milner type system Haskell is based on essentially does not require any type annotations [1]. By convention, every top-level declaration is annotated, but that is only for documentation and clarity.

Or did you mean that in comparing OCaml and Haskell to other (imperative) languages?

[1] There are a few buts that don't have much to do with the argument, but I'll list them here anyway:

1) Sometimes the type you end up with is too ambiguous and you'll need type annotations: E.g. what is the type of the term "2+3"? It is something like "Num a => a" (read: any type that is roughly number-like), but that is not useful if you want to run the program. However, in practice you won't need an annotation in almost all cases as long as some function you work with restricts the type.

2) Some Haskell extensions increase ambiguity in certain cases.

F# would probably sit in there somewhere too a little more on the app than system side, although you don't see many uses of the more low-level stuff that's been made available in the later releases of .NET, it's there for use in F#

Is Haskell a good fit for your hybrid category, similar to go and ocaml, considering it also compiles to native?

I haven't heard of Haskell being used for the kind of "high level" systems programming that go is used for.

Why do you think D isn't an option?

That language is C# not OCaml, specially with the improvements done after version 7.

> no major blunders

No multithreading seems to be a pretty big problem. Hopefully, it will be fixed soon, but still