
State of Multicore OCaml [pdf] - systems
http://kcsrk.info/slides/mcocaml_gallium.pdf
======
scott_s
I was tickled to see that the multicore memory allocator they're implementing
is based on the multithreaded memory allocator I worked on in grad school
([http://www.scott-a-s.com/files/ismm06.pdf;](http://www.scott-
a-s.com/files/ismm06.pdf;)
[https://github.com/scotts/streamflow/](https://github.com/scotts/streamflow/)).

------
kcsrk
The author of the talk here. I am excited about the Multicore OCaml
upstreaming plan.

We're going to phase it into 3 distinct phases. First, we will upstream the
multicore runtime so that it co-exists with the current runtime as a non-
default option. This will give a chance to test and tune the new GC in the
wild. Once we are happy with it, it will be made the default.

The second PR would be support for fibers -- linear delimited continuations
without the syntax extensions (exposed as primitives in the Obj module). This
will help us test the runtime support for fibers and prototype programs.

The last PR would be effect handlers _with an effect system_. Any unhandled
user-defined effects would be caught statically by the type system. The effect
system is particularly useful not just for writing correct programs, but to
target JavaScript using the js_of_ocaml compiler where we can selectively CPS
translate the effectful bits à la Koka. As a result, we will retain the
performance of direct-style code and pay extra cost only for the code that
uses effect handlers. In the future, we will extend it to track built-in OCaml
effects such as IO and mutable refs. At that point, we can statically
distinguish pure (as Haskell defines it) functions from impure ones without
having to use Monad transformers for the code that mixes multiple effects. I'd
recommend Leo White's talk [0] on effect handlers for a preview of how this
system would look like.

[0] [https://www.janestreet.com/tech-talks/effective-
programming/](https://www.janestreet.com/tech-talks/effective-programming/)

------
laylomo2
There is also a report on discuss.ocaml.org thanks to gasche:
[https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-
june...](https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-
june-2018-development-meeting-in-paris/2202)

------
xvilka
What really surprised me, that Facebook with so active usage of ReasonML
doesn't push/sponsor Multicore OCaml. Surely that will improve performance in
their high-load setups.

~~~
thomasjames
ReasonML has only very superficial changes to ML using the ppx AST extension
framework. Multicore GCs are not really what Facebook planned on contributing,
or at least has shown signs of contributing yet. It is also a bit outside of
the scope of their project since they (mainly) market reason for compiling to
JS VMs.

------
elcritch
Now between fibers and effectual types one could implement an Erlang
interpreter pretty readily. That’d be interesting!

Or perhaps port or create a system similar to OTP using the effects, fibers,
and threads.

------
qop
The next two years or so will be really exciting.

Rust is beginning to understand that they need more stability and LTS
versions, and libraries are blossoming nicely.

Ocaml already has a very mature module ecosystem and is now becoming safe and
modern.

I think rust will still have an edge in adoption due to its portrayal as C++
unfucked, but ocaml is definitely the easier tool to work with, imo. And maybe
that will change.

I don't think even linear types and multicore would be enough for ocaml to
make any significant dent in the systems programming world. Rist and
C/C++/D/Zig all do memory management too conveniently, and it opens doors too
close to the bottom for ocaml to keep up.

Any ocaml hackers: would you want to write system drivers in ocaml? Why/ why
not?

~~~
isakkeyten
Hijacking this thread to ask you this.

What should I learn if I want to develop desktop apps and I like functional
programming? I feel like most of the cool 'new' programming languages are OOP
(rust, go, scala).

~~~
toolslive
after some functional programming experience, you may learn that functions
just compose more elegantly than objects. "Objects are a poor man's closures"
(NN)

~~~
jcmoscon
I can't do OO anymore after I learned FP!

~~~
Koshkin
Aren't these things orthogonal to each other?

~~~
crimsonalucard
OOP as described by java and C++ involves a graph of objects changing each
others' state. This is not an orthogonal pattern to functional programming.

If you're thinking of functions operating on immutable objects and returning
new objects then that is not typically what we refer to as a OOP pattern
though technically it may fit the definition.

~~~
pjmlp
Java and C++ are just one way of doing OOP.

More universities should spend time teaching BETA, Self, CLOS, Smalltak,
component based architectures.

~~~
crimsonalucard
I know. The dominant paradigm has changed the definition of the vernacular.
Right now the default definition of OOP is the Java and C++ way unless you
explicitly state otherwise.

