12 ms·

Each year I think wether should I learn OCaml or not. What is the current state of multi-thread OCaml? Is that a game changer or just a cool feature? I can't un

by G4BB3R 6y ago

Each year I think wether should I learn OCaml or not. What is the current state of multi-thread OCaml? Is that a game changer or just a cool feature? I can't understand why OCaml doesn't have mass adoption.

doteka 6y ago
I think Rust kind of stole OCaml’s thunder. It has most of the same benefits, with a mostly familiar syntax and a lot of industry buy-in. And with recent versions, I never find myself fighting the borrow checker like I used to.
- pjmlp 6y ago
  I rather have the productivity of a tracing GC. I don't see Rust being the best option for anything other than low level systems code.
- vmchale 6y ago
  Really? Just made me more reluctant to use a language without sum types :p
- zucker42 6y ago
  I don't know. I think Scala and F# have stolen OCaml's thunder more than Rust. While Rust has been inspired by ML, OCaml and Rust have much different usecases.
  - srean 6y ago
    Other than interop with .NET does F# bring anything more ? Perhaps a little cleaner syntax. One thing F# does not bring is Ocaml's powerful module system
    - deleted 6y ago
      [deleted]
    - zucker42 6y ago
      I'd agree that interop with .NET is the main advantage of F# over OCaml. My point was more that I think OCaml competes mostly with other functional and more generally GCed languages, not a language like Rust.
non-entity 6y ago
I took a brief look at OCaml and from what I've read the tooling and ecosystem has been a bit of a pain in the past. And while it may be minor, from what I understand OCaml on Windows isnt a thing without cygwin or WSL.
- mseri 6y ago
  Windows support is the upcoming focus: https://youtu.be/E8T_4zqWmq8?t=3459 https://youtu.be/E8T_4zqWmq8?t=3459
dunefox 6y ago
The language itself is great, the user experience is quite bad - although supposedly it has gotten a bit better recently.
mseri 6y ago
Multicore development has sped up pace, there are many changes in the latest two compiler internals that were made in order to accommodate the new GC, and you can read updates on those works in this year's' POPL and ICFP talks. Multicore benchmarks are on github and are used to drive the changes. When used properly you can see large speedups without affecting much the speed of single core OCaml (which is quite fast). If you want more details there are monthly updates now on the discuss.ocaml.org forum (just search for multicore). We usually post them also on HN when there is some meat. Even though rust (or Julia if we talk about numerics) can clearly be many times faster, it is an imperative language with a functional feeling (don't take it in the wrong way, I think both are great languages for different reasons). For less performance critical applications I think OCaml is still worth, it is reasonably fast for a GCed language, has a great type system and the compiler is egregiously fast. Multicore makes quite a difference in performances for certain numerical code, however it will be hard (if even possible at all) to reach the speed of fine-tuned Julia, C/C++, Fortran or Rust (which does not yet have a proper numerical framework though, afaik). The approach of owl has been to introduce an engine (wol-symbolic) that compiles computation graphs to ONNX format, so that they can be executed on GPU, FPGA, different engines, releasing from it the burden of supporting those various backends. Personally I find the ease of maintenance and refactoring with reasonable speed a good compromise, I think its sweet spot is for exploratory code that does not require bare metal speed and yet should be fast enough.
- sadiq 6y ago
  Just to add to this good summary, OCaml already has some support for parallelism that would be useful for scientific computation. Essentially you can already have multi-threaded OCaml programs as long as only one thread is using the OCaml runtime at any point in time. For numerical code where you might be spending the vast majority of your time in external libraries this ends up not being a major problem. It's not a dissimilar story for where Python is. What Multicore OCaml adds is the ability to run multiple threads of OCaml code at the same time (we call them Domains, to avoid confusing them with existing Threads - which can coexist). There's an entry on the Multicore wiki that gives some more depth: https://github.com/ocaml-multicore/ocaml-multicore/wiki/Concurrency-and-parallelism-design-notes https://github.com/ocaml-multicore/ocaml-multicore/wiki/Conc... In terms of the project you can also follow progress in the Multicore Monthlies: https://discuss.ocaml.org/tag/multicore-monthly https://discuss.ocaml.org/tag/multicore-monthly as well as see the in-progress and merged multicore PRs that are hitting upstream ocaml: https://github.com/ocaml/ocaml/pulls?q=is%3Apr+label%3Amulticore-prerequisite+ https://github.com/ocaml/ocaml/pulls?q=is%3Apr+label%3Amulti... If you want to know more about how the multicore runtime works the recent ICFP2020 paper has a lot of detail: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663 and KC's presentation is worth a watch: https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be&t=6198 https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be...
wtetzner 6y ago
> I can't understand why OCaml doesn't have mass adoption. The biggest problem with OCaml is the tooling (and Windows support is pretty rough). It is getting better, but it's certainly not as easy as using something like Cargo.
steev 6y ago
> I can't understand why OCaml doesn't have mass adoption. Probably for the exact same reason each year you think about learning OCaml you decide not to (I mean this sincerely, not trying to be snide). I think the main reasons it doesn't see mass adoption in industry: * There are only two major companies that do a substantial amount of OCaml that I can think of off the top of my head, Jane Street and Ahrefs. Facebook does some OCaml too but I don't think it's a core part of their stack. * The tooling is lacking. * People have an easier time learning Python or Java so you'll have a larger pool of candidates if you use one of those languages.
- vmchale 6y ago
  > Facebook does some OCaml too Using an ML or a Lisp for language tooling is the way to go. Nothing else in that league.
  - pjmlp 6y ago
    I would add Prolog to that list.
  - weeniehutjr420 6y ago
    How about Haskell?
    - choeger 6y ago
      Haskell is like the nerdy cousin of the ML family. Everyone knows he's smart, but no one would think to ask him to fix the kitchen sink or install the new dishwasher. Seriously, Haskell is massively impressive, both as a research language and as an implementation. But it does not shed that certain research attitude. Every known problem seems to be boring. "Oh you want a proxying http server? No problem, this is just the inversion of the endofoo over the category of abstract Monobars!". Sometimes I get the feeling that no one focuses on shipping actual software with Haskell.
      - greggyb 6y ago
yodsanklai 6y ago
As others said, I think the language is great. Things get uglier when you want to go from OCaml to real world OCaml. The standard library is lacking, which means you have to use Jane Street libraries or other third-party library which may not be very robust, stable, documented. Jane Street libraries are fine but they significantly increase the complexity of the langage. They also encourage you into doing things a certain way (using sexp, ppx). Also, I find monad-based asynchronous programming to be quite tedious. I feel like a lot of the simplicity and elegance of OCaml is being lost. In terms of fun, I'd rather write a server in Go than in OCaml.
- mseri 6y ago
  There is another widely used standard library: containers. Which is much less opinionated and aims to extend the standard library instead of replacing it. In many use it in production, so it quite well tested and polished. It is also true that the standard library is growing faster recently, so maybe this will become less of a problem I. The future.
- ducaale 6y ago
  >Also, I find monad-based asynchronous programming to be quite tedious. Have you tried using OCaml's monadic let expressions? It was introduced on verion 4.08 and they share similarity with F# computation expressions. * https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-... * https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html
centimeter 6y ago
As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are more advanced topics you can go into with Haskell, especially around the type system. There is nothing I can think of that you can learn in ocaml that you can’t learn in Haskell * More fun - if you want to, there are lots of entertaining/aesthetically pleasing things you can do with writing concise/elegant programs or proving properties using the type system Also, a lot of the putative advantages of OCaml over Haskell (e.g. “Monads seem complicated”) disappear when you use OCaml in practice. This isn’t to shit on OCaml - it’s better than 95% of languages out there. But if you’re starting from scratch with no prior investment, I would not prefer it in any scenario I can think of.
- smabie 6y ago
  I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
  - brmgb 6y ago
    > I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
    - smabie 6y ago
heavyset_go 6y ago
> Each year I think wether should I learn OCaml or not Ask yourself if you want to learn OCaml for practical reasons, or because you want to satisfy an internal itch. Both are perfectly good reasons to learn a language. When I went to evaluate OCaml, I realized I wouldn't get much practical use out of it despite my curiosity, and focused on learning skills that I would get practical use out of. I'm happy with my choice, and plan to revisit the language to satisfy my curiosity at some other point.
gnufx 6y ago
The most serious scientific computation gets done on distributed memory systems, not shared. That likely just means bindings to MPI and other appropriate libraries. That will often do pretty well on shared memory too.

by G4BB3R 6y ago

doteka 6y ago

I think Rust kind of stole OCaml’s thunder. It has most of the same benefits, with a mostly familiar syntax and a lot of industry buy-in. And with recent versions, I never find myself fighting the borrow checker like I used to.

pjmlp 6y ago
I rather have the productivity of a tracing GC. I don't see Rust being the best option for anything other than low level systems code.
vmchale 6y ago
Really? Just made me more reluctant to use a language without sum types :p
zucker42 6y ago
I don't know. I think Scala and F# have stolen OCaml's thunder more than Rust. While Rust has been inspired by ML, OCaml and Rust have much different usecases.
- srean 6y ago
  Other than interop with .NET does F# bring anything more ? Perhaps a little cleaner syntax. One thing F# does not bring is Ocaml's powerful module system
  - deleted 6y ago
    [deleted]
  - zucker42 6y ago
    I'd agree that interop with .NET is the main advantage of F# over OCaml. My point was more that I think OCaml competes mostly with other functional and more generally GCed languages, not a language like Rust.

non-entity 6y ago

I took a brief look at OCaml and from what I've read the tooling and ecosystem has been a bit of a pain in the past. And while it may be minor, from what I understand OCaml on Windows isnt a thing without cygwin or WSL.

mseri 6y ago
Windows support is the upcoming focus: https://youtu.be/E8T_4zqWmq8?t=3459 https://youtu.be/E8T_4zqWmq8?t=3459

dunefox 6y ago

The language itself is great, the user experience is quite bad - although supposedly it has gotten a bit better recently.

mseri 6y ago

Multicore development has sped up pace, there are many changes in the latest two compiler internals that were made in order to accommodate the new GC, and you can read updates on those works in this year's' POPL and ICFP talks. Multicore benchmarks are on github and are used to drive the changes. When used properly you can see large speedups without affecting much the speed of single core OCaml (which is quite fast). If you want more details there are monthly updates now on the discuss.ocaml.org forum (just search for multicore). We usually post them also on HN when there is some meat. Even though rust (or Julia if we talk about numerics) can clearly be many times faster, it is an imperative language with a functional feeling (don't take it in the wrong way, I think both are great languages for different reasons). For less performance critical applications I think OCaml is still worth, it is reasonably fast for a GCed language, has a great type system and the compiler is egregiously fast. Multicore makes quite a difference in performances for certain numerical code, however it will be hard (if even possible at all) to reach the speed of fine-tuned Julia, C/C++, Fortran or Rust (which does not yet have a proper numerical framework though, afaik). The approach of owl has been to introduce an engine (wol-symbolic) that compiles computation graphs to ONNX format, so that they can be executed on GPU, FPGA, different engines, releasing from it the burden of supporting those various backends. Personally I find the ease of maintenance and refactoring with reasonable speed a good compromise, I think its sweet spot is for exploratory code that does not require bare metal speed and yet should be fast enough.

sadiq 6y ago
Just to add to this good summary, OCaml already has some support for parallelism that would be useful for scientific computation. Essentially you can already have multi-threaded OCaml programs as long as only one thread is using the OCaml runtime at any point in time. For numerical code where you might be spending the vast majority of your time in external libraries this ends up not being a major problem. It's not a dissimilar story for where Python is. What Multicore OCaml adds is the ability to run multiple threads of OCaml code at the same time (we call them Domains, to avoid confusing them with existing Threads - which can coexist). There's an entry on the Multicore wiki that gives some more depth: https://github.com/ocaml-multicore/ocaml-multicore/wiki/Concurrency-and-parallelism-design-notes https://github.com/ocaml-multicore/ocaml-multicore/wiki/Conc... In terms of the project you can also follow progress in the Multicore Monthlies: https://discuss.ocaml.org/tag/multicore-monthly https://discuss.ocaml.org/tag/multicore-monthly as well as see the in-progress and merged multicore PRs that are hitting upstream ocaml: https://github.com/ocaml/ocaml/pulls?q=is%3Apr+label%3Amulticore-prerequisite+ https://github.com/ocaml/ocaml/pulls?q=is%3Apr+label%3Amulti... If you want to know more about how the multicore runtime works the recent ICFP2020 paper has a lot of detail: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663 and KC's presentation is worth a watch: https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be&t=6198 https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be...

wtetzner 6y ago

> I can't understand why OCaml doesn't have mass adoption. The biggest problem with OCaml is the tooling (and Windows support is pretty rough). It is getting better, but it's certainly not as easy as using something like Cargo.

steev 6y ago

> I can't understand why OCaml doesn't have mass adoption. Probably for the exact same reason each year you think about learning OCaml you decide not to (I mean this sincerely, not trying to be snide). I think the main reasons it doesn't see mass adoption in industry: * There are only two major companies that do a substantial amount of OCaml that I can think of off the top of my head, Jane Street and Ahrefs. Facebook does some OCaml too but I don't think it's a core part of their stack. * The tooling is lacking. * People have an easier time learning Python or Java so you'll have a larger pool of candidates if you use one of those languages.

vmchale 6y ago
> Facebook does some OCaml too Using an ML or a Lisp for language tooling is the way to go. Nothing else in that league.
- pjmlp 6y ago
  I would add Prolog to that list.
- weeniehutjr420 6y ago
  How about Haskell?
  - choeger 6y ago
    Haskell is like the nerdy cousin of the ML family. Everyone knows he's smart, but no one would think to ask him to fix the kitchen sink or install the new dishwasher. Seriously, Haskell is massively impressive, both as a research language and as an implementation. But it does not shed that certain research attitude. Every known problem seems to be boring. "Oh you want a proxying http server? No problem, this is just the inversion of the endofoo over the category of abstract Monobars!". Sometimes I get the feeling that no one focuses on shipping actual software with Haskell.
    - greggyb 6y ago

yodsanklai 6y ago

As others said, I think the language is great. Things get uglier when you want to go from OCaml to real world OCaml. The standard library is lacking, which means you have to use Jane Street libraries or other third-party library which may not be very robust, stable, documented. Jane Street libraries are fine but they significantly increase the complexity of the langage. They also encourage you into doing things a certain way (using sexp, ppx). Also, I find monad-based asynchronous programming to be quite tedious. I feel like a lot of the simplicity and elegance of OCaml is being lost. In terms of fun, I'd rather write a server in Go than in OCaml.

mseri 6y ago
There is another widely used standard library: containers. Which is much less opinionated and aims to extend the standard library instead of replacing it. In many use it in production, so it quite well tested and polished. It is also true that the standard library is growing faster recently, so maybe this will become less of a problem I. The future.
ducaale 6y ago
>Also, I find monad-based asynchronous programming to be quite tedious. Have you tried using OCaml's monadic let expressions? It was introduced on verion 4.08 and they share similarity with F# computation expressions. * https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-... * https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html

centimeter 6y ago

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are more advanced topics you can go into with Haskell, especially around the type system. There is nothing I can think of that you can learn in ocaml that you can’t learn in Haskell * More fun - if you want to, there are lots of entertaining/aesthetically pleasing things you can do with writing concise/elegant programs or proving properties using the type system Also, a lot of the putative advantages of OCaml over Haskell (e.g. “Monads seem complicated”) disappear when you use OCaml in practice. This isn’t to shit on OCaml - it’s better than 95% of languages out there. But if you’re starting from scratch with no prior investment, I would not prefer it in any scenario I can think of.

smabie 6y ago
I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
- brmgb 6y ago
  > I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
  - smabie 6y ago

heavyset_go 6y ago

> Each year I think wether should I learn OCaml or not Ask yourself if you want to learn OCaml for practical reasons, or because you want to satisfy an internal itch. Both are perfectly good reasons to learn a language. When I went to evaluate OCaml, I realized I wouldn't get much practical use out of it despite my curiosity, and focused on learning skills that I would get practical use out of. I'm happy with my choice, and plan to revisit the language to satisfy my curiosity at some other point.

gnufx 6y ago

The most serious scientific computation gets done on distributed memory systems, not shared. That likely just means bindings to MPI and other appropriate libraries. That will often do pretty well on shared memory too.