12 ms·

OCaml 5.0 Alpha Release

226 points by momentoftop 4y ago

samuell 4y ago
Checked in OCaml a few years ago. I remember there being plans for improved concurrency/parallelism, set for the future. Any progress on this in this release?
- vphantom 4y ago
  That's exactly what version 5 brings: multicore is fully merged in now.
  - samuell 4y ago
    Cool, thanks for info!
pdimitar 4y ago
Can't wait for tinkering with OCaml when 5.0 is stable. Pretty sure the community will invent amazing libraries for parallel computation as well. Maybe finally Rust+tokio projects will have some actual competition!
- _flux 4y ago
  OCaml is possibly my favorite language, along with Rust, and what I hope from the Santa is projects like https://github.com/tezedge/ocaml-interop https://github.com/tezedge/ocaml-interop to become mature. I think all these "properly typed" languages should aspire to have great interoperability: after all, they have types to help. But I realize there can be big technical difficulties in making it safe, in particular with garbage collection..
  - CodeSgt 4y ago
    How does it compare to Rust? What do you like about each?
    - ChadNauseam 4y ago
      The garbage collector is nice because sometimes you don't want to think about memory management or the borrow checker. The syntax is really cool, it looks like python but it's completely whitespace insensitive. The module system is neat, and I actually like writing module interfaces (which are basically analogous to header files in C/C++). It makes dependency injection trivial, because you can have a module say "I depend on a module with this interface, but the caller can choose which one", which is more useful than it sounds. It's also a functional language, so you have very little mutability, and it supports """monads""" with its super innovative "monadic let" syntax. (It's basically like overloading the semicolon, which probably doesn't make any sense, but it's really cool.) Dune is a very pleasant build system and Esy is a very pleasant package manager. The language server is good. I'd say in this dimension it's competitive with Rust. There's really quite a lot to like about OCaml. My biggest gripe with it is no typeclasses/traits. But I have hope that modular implicits will land within our lifetimes.
      - tgflynn 4y ago
        What exactly is Esy ? I hadn't heard of it before and its website doesn't seem to provide an obvious answer to that question. You say it is a package manager. Is it supposed to replace opam ? If so what does it offer that opam doesn't ?
        pdimitar 4y ago
        It's like Rust's cargo or Elixir's mix. A task runner, mostly.
        ChadNauseam 4y ago
        It's a package manager that replaces Opam. It doesn't require switches and it caches builds of packages across projects.
      - UncleOxidant 4y ago
        > The syntax is really cool, it looks like python I'm squinting really hard but not seeing the resemblance.
  - anentropic 4y ago
    I'm a bit confused... the readme of ocaml-interop says it's "inspired by" ocaml-rs while ocaml-rs says it "uses ocaml-interop behind the scenes" and "also exports an interop module, which is an alias for ocaml_interop and the two interfaces can be combined if desired" from a cursory look over ocaml-rs seems possibly the one to use, as the more comprehensive project
    - gadmm 4y ago
      The development of the OCaml-Rust interface is a bit organic. `ocaml-interop` aims to be a low-level but safe interface. At Inria we worked with the author to integrate ideas about using Rust's type system to safely work with a GC. We have more ideas to make it better; if someone wants to commit engineering time in this area they should feel encouraged to contact me.
- wyager 4y ago
  An ML that competes with rust+tokio is an exact description of haskell. It's had the best multicore runtime and concurrency primitives of any general purpose language for quite some time. No need to wait.
  - pdimitar 4y ago
    Including work-stealing scheduler and runtime? Ability to just spawn 50_000 tasks -- regardless of whether they're CPU-intensive or I/O bound -- and have the runtime handle it speedily? I've heard Haskell praise a good amount of times but at the same time many people also said that doing actual work with it has more friction than it should, so I don't know.
    - shirogane86x 4y ago
      I don't know if those things you ask are in Haskell specifically, but what I do know is that Haskell concurrency is pretty much best in class. You get channels (Control.Concurrent.Chan is in the stdlib), STM, green threads (forkIO). You can also get stuff like async (from the async library) or streamly (even higher level than traditional async). I'm not 100% sure if you can push insane speeds with it (even though Haskell is really fast, it's just very tricky to optimize correctly) like you can with Rust, but the developer experience on concurrency is just through the roof, imho (dare I say even better than rust). STM is just the best kind of magic.
    - pjmlp 4y ago
      Yes, as they say back home, "when you are going I am coming back". "Parallel and Concurrent Programming in Haskell" (2013) https://www.oreilly.com/library/view/parallel-and-concurrent/9781449335939/ https://www.oreilly.com/library/view/parallel-and-concurrent...
      - pdimitar 4y ago
        I've heard that many times, still skeptical after trying Haskell thrice. Have Haskell's ergonomics improved? I feel your snark is unjustified. You might be putting people in two extremes: wise elders and hip kids. There's a huge amount of people in-between however. (Also, the saying actually is: "You're going to where I am coming back from".) Find me something like Erlang/Elixir with the speed of Rust and I won't learn another programming language ever again. No? Then the search continues. So far Haskell hasn't impressed. In all honesty Rust is quite hard to put in that niche as well since its `async` stuff is extremely annoying and hard to get right but I guess the tries are still ongoing. OCaml is progressing but who knows when will they get there.
- kcsrk 4y ago
  For nested parallel computations (think Scientific Programming, where one would use OpenMP, Rust Rayon, etc), we have domainslib [1]. Eio, a direct-style, effect-based IO library is pretty competitive against Rust Tokio [2]. The performance will only get better as we get closer to the 5.0 release. [1] https://github.com/ocaml-multicore/domainslib https://github.com/ocaml-multicore/domainslib [2] See the http server performance graphs at https://tarides.com/blog/2022-03-01-segfault-systems-joins-tarides#ecosystem https://tarides.com/blog/2022-03-01-segfault-systems-joins-t...
  - pdimitar 4y ago
    Very impressive, thank you. I admit I'm not much of an early adopter -- hence my comment that I'll be waiting for the official 5.0 release. I've scanned several articles (some made by you) and I very much like what I'm seeing.
the_duke 4y ago
I heard that 5.0 does not include (user visible) effects (yet?). Is this planned for after 5.0? Anywhere I can learn more? Getting an effects system with handlers in a (semi)large and mature language is a pretty big step. The Koka language [1] has a brilliant implementation of algebraic effects. Sadly it's a research language that doesn't see much development. [1] https://koka-lang.github.io/koka/doc/book.html#why-handlers https://koka-lang.github.io/koka/doc/book.html#why-handlers
- octachron 4y ago
  The effect system is here, and it can already be used. However, the integration within the (surface) language and its type system is still a work in progress. Thus to explore the use of effects, you need to use the experimental Effect (https://github.com/ocaml/ocaml/blob/trunk/stdlib/effect.mli https://github.com/ocaml/ocaml/blob/trunk/stdlib/effect.mli) module which gives you access to low-level primitives for defining effects, installing an effect handler and resuming a continuation. The module will be considered as experimental in OCaml 5.0 and subsequent version of OCaml 5 will refine the integration within the language. The objective here was to decouple the multicore runtime work from the higher-level language design questions.
  - kcsrk 4y ago
    I would also recommend reading the effect handlers tutorial in OCaml 5.0 manual: https://kcsrk.info/webman/manual/effects.html https://kcsrk.info/webman/manual/effects.html.
  - momentoftop 4y ago
    Is there any plan to have effect types like in koka, where the effects that a function performs are visible in the type, and handling an effect eliminates it from the function's type?
    - octachron 4y ago
      The medium-term plan is indeed to have such a typed effect system. This one of the reason why the effect system is still considered to be experimental: we expect to see some breaking changes once effects become typed.
ufo 4y ago
Does anyone know what are the main new features of Ocaml 5.0?
- octachron 4y ago
  Essentially, OCaml 5.0 is OCaml 4.14 with a fully rewritten runtime which introduces support for parallelism (no more global runtime lock) and an experimental version of algebraic effects.
  - amelius 4y ago
    > no more global runtime lock Perhaps Python devs should consider transpiling to OCaml ;)
    - giraffe_lady 4y ago
      The naming potential is incredible at least.
- kcsrk 4y ago
  Parallelism [1] and native-support for concurrency through effect handlers [2]. [1] https://kcsrk.info/webman/manual/parallelism.html https://kcsrk.info/webman/manual/parallelism.html [2] https://kcsrk.info/webman/manual/effects.html https://kcsrk.info/webman/manual/effects.html
sunflowerdeath 4y ago
For almost as long as I've been programming, I find Ocaml a fantastic language, which just lacked some development tools and improved concurrency. I still believe that under the right circumstances it could become a mainstream language.
- StevePerkins 4y ago
  If this were really true though, then wouldn't F# be bigger than it is?
  - ipiz0618 4y ago
    F# is a fantastic language! However, its official documentation is a bit lacking (like the C# ones). Also having developed some reactive applications I'd say .NET core needs some improvements before people can have fun developing desktop or web apps with it
  - mm007emko 4y ago
    Exactly. Functional programming has been around for quite a while, it just recently became the FAD of the day, just search youtube for "functional programming in javascript". This will fade away in just a couple of years. F# is an interesting language and yes, I used it at work a couple of times. However finding a programmer who is into that is hard and the HR "partners" will kill you because people like these can't be treated as cheap replaceable resources. So it was F# prototype -> C# production. Attempts to introduce a new language or a tech stack usually failed because the decision makers (managers) were concerned about "how many people can I hire within a month" than anything else - nobody was fired for picking Java, C# or JavaScript (TypeScript) for the next project and staffing accordingly. Languages like OCaml, Haskell, Lisp (whatever flavour you pick) or Prolog will never become mainstream. Should they even? My favourite is one of them for my general hacking or research projects; not sure I'd like to use it in a corporate job (which I have right now). Small efficient team in a tech start-up? Hell yeah! Mainstream mundane programming? OMG NO! Horses for courses. Hearses are not mainstream vehicles yet all of us will need a ride in one occasionally. Does it mean they should become popular and mainstream? :-D
sigzero 4y ago
Whenever an OCaml post comes up the biggest comment about the language was "no concurrency/parallelism". I hope this brings more people into the OCaml world. Awesome job to all the devs.
- dunefox 4y ago
  For me it's the several stdlibs and Unicode strings.
  - sidkshatriya 4y ago
    Haskell has many preludes also but people seem to embrace that flexibility there. I don't know much about the intricacies of unicode but as usual there are some OCaml libraries available. Are they incomplete/insufficient in some way?
sudarshnachakra 4y ago
Hoping this release will bring the below advantages. 1. A statically compiled language with GC-d runtime, which compiles quicker than golang 2. Something that brings algebraic effects to the mainstream and with it an arguably better model for concurrency / parallelism 3. Support value types to take advantage of modern CPU caches Finally golang finds some real competition (from a very unlikely source though). Hoping ReasonML will become more popular with this release with true parallelism and nice concurrency.
- momentoftop 4y ago
  ReasonML is now Rescript, and is still using the 4.06 compiler. I think the idea is to move ahead largely independently of Ocaml, and that a move to 5.0 now is probably seriously ambitious given the runtime overhaul.
  - cassepipe 4y ago
    So it's Reason, not ReasonML which the umbrella project's name, and Rescript is a imcompatible syntax split from the Bucklescript team (that previously transpiled Reason to JS). Bucklescript's new name is... Rescript. But not everyone agrees with the split and work is being done on Melange to replace Bucklescript : https://github.com/melange-re/melange https://github.com/melange-re/melange Ultimately JsOfOcaml can directly transpile Ocaml to JS.
  - mseri 4y ago
    Reason and ReScript are two different projects. You can still use Reason to compile natively and to JavaScript via js_of_ocaml.
  - dmitriid 4y ago
    > ReasonML is now Rescript Apparently it's not. The whole thing is a mess :) https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc...

226 points by momentoftop 4y ago

Checked in OCaml a few years ago. I remember there being plans for improved concurrency/parallelism, set for the future. Any progress on this in this release?

vphantom 4y ago
That's exactly what version 5 brings: multicore is fully merged in now.
- samuell 4y ago
  Cool, thanks for info!

pdimitar 4y ago

Can't wait for tinkering with OCaml when 5.0 is stable. Pretty sure the community will invent amazing libraries for parallel computation as well. Maybe finally Rust+tokio projects will have some actual competition!

_flux 4y ago
OCaml is possibly my favorite language, along with Rust, and what I hope from the Santa is projects like https://github.com/tezedge/ocaml-interop https://github.com/tezedge/ocaml-interop to become mature. I think all these "properly typed" languages should aspire to have great interoperability: after all, they have types to help. But I realize there can be big technical difficulties in making it safe, in particular with garbage collection..
- CodeSgt 4y ago
  How does it compare to Rust? What do you like about each?
  - ChadNauseam 4y ago
    The garbage collector is nice because sometimes you don't want to think about memory management or the borrow checker. The syntax is really cool, it looks like python but it's completely whitespace insensitive. The module system is neat, and I actually like writing module interfaces (which are basically analogous to header files in C/C++). It makes dependency injection trivial, because you can have a module say "I depend on a module with this interface, but the caller can choose which one", which is more useful than it sounds. It's also a functional language, so you have very little mutability, and it supports """monads""" with its super innovative "monadic let" syntax. (It's basically like overloading the semicolon, which probably doesn't make any sense, but it's really cool.) Dune is a very pleasant build system and Esy is a very pleasant package manager. The language server is good. I'd say in this dimension it's competitive with Rust. There's really quite a lot to like about OCaml. My biggest gripe with it is no typeclasses/traits. But I have hope that modular implicits will land within our lifetimes.
    - tgflynn 4y ago
      What exactly is Esy ? I hadn't heard of it before and its website doesn't seem to provide an obvious answer to that question. You say it is a package manager. Is it supposed to replace opam ? If so what does it offer that opam doesn't ?
      - pdimitar 4y ago
        It's like Rust's cargo or Elixir's mix. A task runner, mostly.
      - ChadNauseam 4y ago
        It's a package manager that replaces Opam. It doesn't require switches and it caches builds of packages across projects.
    - UncleOxidant 4y ago
      > The syntax is really cool, it looks like python I'm squinting really hard but not seeing the resemblance.
- anentropic 4y ago
  I'm a bit confused... the readme of ocaml-interop says it's "inspired by" ocaml-rs while ocaml-rs says it "uses ocaml-interop behind the scenes" and "also exports an interop module, which is an alias for ocaml_interop and the two interfaces can be combined if desired" from a cursory look over ocaml-rs seems possibly the one to use, as the more comprehensive project
  - gadmm 4y ago
    The development of the OCaml-Rust interface is a bit organic. `ocaml-interop` aims to be a low-level but safe interface. At Inria we worked with the author to integrate ideas about using Rust's type system to safely work with a GC. We have more ideas to make it better; if someone wants to commit engineering time in this area they should feel encouraged to contact me.
wyager 4y ago
An ML that competes with rust+tokio is an exact description of haskell. It's had the best multicore runtime and concurrency primitives of any general purpose language for quite some time. No need to wait.
- pdimitar 4y ago
  Including work-stealing scheduler and runtime? Ability to just spawn 50_000 tasks -- regardless of whether they're CPU-intensive or I/O bound -- and have the runtime handle it speedily? I've heard Haskell praise a good amount of times but at the same time many people also said that doing actual work with it has more friction than it should, so I don't know.
  - shirogane86x 4y ago
    I don't know if those things you ask are in Haskell specifically, but what I do know is that Haskell concurrency is pretty much best in class. You get channels (Control.Concurrent.Chan is in the stdlib), STM, green threads (forkIO). You can also get stuff like async (from the async library) or streamly (even higher level than traditional async). I'm not 100% sure if you can push insane speeds with it (even though Haskell is really fast, it's just very tricky to optimize correctly) like you can with Rust, but the developer experience on concurrency is just through the roof, imho (dare I say even better than rust). STM is just the best kind of magic.
  - pjmlp 4y ago
    Yes, as they say back home, "when you are going I am coming back". "Parallel and Concurrent Programming in Haskell" (2013) https://www.oreilly.com/library/view/parallel-and-concurrent/9781449335939/ https://www.oreilly.com/library/view/parallel-and-concurrent...
    - pdimitar 4y ago
      I've heard that many times, still skeptical after trying Haskell thrice. Have Haskell's ergonomics improved? I feel your snark is unjustified. You might be putting people in two extremes: wise elders and hip kids. There's a huge amount of people in-between however. (Also, the saying actually is: "You're going to where I am coming back from".) Find me something like Erlang/Elixir with the speed of Rust and I won't learn another programming language ever again. No? Then the search continues. So far Haskell hasn't impressed. In all honesty Rust is quite hard to put in that niche as well since its `async` stuff is extremely annoying and hard to get right but I guess the tries are still ongoing. OCaml is progressing but who knows when will they get there.
kcsrk 4y ago
For nested parallel computations (think Scientific Programming, where one would use OpenMP, Rust Rayon, etc), we have domainslib [1]. Eio, a direct-style, effect-based IO library is pretty competitive against Rust Tokio [2]. The performance will only get better as we get closer to the 5.0 release. [1] https://github.com/ocaml-multicore/domainslib https://github.com/ocaml-multicore/domainslib [2] See the http server performance graphs at https://tarides.com/blog/2022-03-01-segfault-systems-joins-tarides#ecosystem https://tarides.com/blog/2022-03-01-segfault-systems-joins-t...
- pdimitar 4y ago
  Very impressive, thank you. I admit I'm not much of an early adopter -- hence my comment that I'll be waiting for the official 5.0 release. I've scanned several articles (some made by you) and I very much like what I'm seeing.

the_duke 4y ago

I heard that 5.0 does not include (user visible) effects (yet?). Is this planned for after 5.0? Anywhere I can learn more? Getting an effects system with handlers in a (semi)large and mature language is a pretty big step. The Koka language [1] has a brilliant implementation of algebraic effects. Sadly it's a research language that doesn't see much development. [1] https://koka-lang.github.io/koka/doc/book.html#why-handlers https://koka-lang.github.io/koka/doc/book.html#why-handlers

octachron 4y ago
The effect system is here, and it can already be used. However, the integration within the (surface) language and its type system is still a work in progress. Thus to explore the use of effects, you need to use the experimental Effect (https://github.com/ocaml/ocaml/blob/trunk/stdlib/effect.mli https://github.com/ocaml/ocaml/blob/trunk/stdlib/effect.mli) module which gives you access to low-level primitives for defining effects, installing an effect handler and resuming a continuation. The module will be considered as experimental in OCaml 5.0 and subsequent version of OCaml 5 will refine the integration within the language. The objective here was to decouple the multicore runtime work from the higher-level language design questions.
- kcsrk 4y ago
  I would also recommend reading the effect handlers tutorial in OCaml 5.0 manual: https://kcsrk.info/webman/manual/effects.html https://kcsrk.info/webman/manual/effects.html.
- momentoftop 4y ago
  Is there any plan to have effect types like in koka, where the effects that a function performs are visible in the type, and handling an effect eliminates it from the function's type?
  - octachron 4y ago
    The medium-term plan is indeed to have such a typed effect system. This one of the reason why the effect system is still considered to be experimental: we expect to see some breaking changes once effects become typed.

ufo 4y ago

Does anyone know what are the main new features of Ocaml 5.0?

octachron 4y ago
Essentially, OCaml 5.0 is OCaml 4.14 with a fully rewritten runtime which introduces support for parallelism (no more global runtime lock) and an experimental version of algebraic effects.
- amelius 4y ago
  > no more global runtime lock Perhaps Python devs should consider transpiling to OCaml ;)
  - giraffe_lady 4y ago
    The naming potential is incredible at least.
kcsrk 4y ago
Parallelism [1] and native-support for concurrency through effect handlers [2]. [1] https://kcsrk.info/webman/manual/parallelism.html https://kcsrk.info/webman/manual/parallelism.html [2] https://kcsrk.info/webman/manual/effects.html https://kcsrk.info/webman/manual/effects.html

sunflowerdeath 4y ago

For almost as long as I've been programming, I find Ocaml a fantastic language, which just lacked some development tools and improved concurrency. I still believe that under the right circumstances it could become a mainstream language.

StevePerkins 4y ago
If this were really true though, then wouldn't F# be bigger than it is?
- ipiz0618 4y ago
  F# is a fantastic language! However, its official documentation is a bit lacking (like the C# ones). Also having developed some reactive applications I'd say .NET core needs some improvements before people can have fun developing desktop or web apps with it
- mm007emko 4y ago
  Exactly. Functional programming has been around for quite a while, it just recently became the FAD of the day, just search youtube for "functional programming in javascript". This will fade away in just a couple of years. F# is an interesting language and yes, I used it at work a couple of times. However finding a programmer who is into that is hard and the HR "partners" will kill you because people like these can't be treated as cheap replaceable resources. So it was F# prototype -> C# production. Attempts to introduce a new language or a tech stack usually failed because the decision makers (managers) were concerned about "how many people can I hire within a month" than anything else - nobody was fired for picking Java, C# or JavaScript (TypeScript) for the next project and staffing accordingly. Languages like OCaml, Haskell, Lisp (whatever flavour you pick) or Prolog will never become mainstream. Should they even? My favourite is one of them for my general hacking or research projects; not sure I'd like to use it in a corporate job (which I have right now). Small efficient team in a tech start-up? Hell yeah! Mainstream mundane programming? OMG NO! Horses for courses. Hearses are not mainstream vehicles yet all of us will need a ride in one occasionally. Does it mean they should become popular and mainstream? :-D

sigzero 4y ago

Whenever an OCaml post comes up the biggest comment about the language was "no concurrency/parallelism". I hope this brings more people into the OCaml world. Awesome job to all the devs.

dunefox 4y ago
For me it's the several stdlibs and Unicode strings.
- sidkshatriya 4y ago
  Haskell has many preludes also but people seem to embrace that flexibility there. I don't know much about the intricacies of unicode but as usual there are some OCaml libraries available. Are they incomplete/insufficient in some way?

sudarshnachakra 4y ago

Hoping this release will bring the below advantages. 1. A statically compiled language with GC-d runtime, which compiles quicker than golang 2. Something that brings algebraic effects to the mainstream and with it an arguably better model for concurrency / parallelism 3. Support value types to take advantage of modern CPU caches Finally golang finds some real competition (from a very unlikely source though). Hoping ReasonML will become more popular with this release with true parallelism and nice concurrency.

momentoftop 4y ago
ReasonML is now Rescript, and is still using the 4.06 compiler. I think the idea is to move ahead largely independently of Ocaml, and that a move to 5.0 now is probably seriously ambitious given the runtime overhaul.
- cassepipe 4y ago
  So it's Reason, not ReasonML which the umbrella project's name, and Rescript is a imcompatible syntax split from the Bucklescript team (that previously transpiled Reason to JS). Bucklescript's new name is... Rescript. But not everyone agrees with the split and work is being done on Melange to replace Bucklescript : https://github.com/melange-re/melange https://github.com/melange-re/melange Ultimately JsOfOcaml can directly transpile Ocaml to JS.
- mseri 4y ago
  Reason and ReScript are two different projects. You can still use Reason to compile natively and to JavaScript via js_of_ocaml.
- dmitriid 4y ago
  > ReasonML is now Rescript Apparently it's not. The whole thing is a mess :) https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc...