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.
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.
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/Conc...
In terms of the project you can also follow progress in the Multicore Monthlies: 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%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 and KC's presentation is worth a watch: https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be...
I'll just note here that this paper is hot off the presses! ICFP is taking place as we speak, this week, Monday to Friday.
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.
Using an ML or a Lisp for language tooling is the way to go. Nothing else in that league.
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.
https://engineering.fb.com/security/fighting-spam-with-haske...
With just a modicum of effort you can easily disprove this feeling.
Care to elaborate on this point? Maybe it's just because I'm coming from Haskell (lol), but my experience with OCaml's tooling has been pretty darn good.
While I don't think there's a heavyweight IDE for OCaml à la IntelliJ, in Emacs I get my error messages inline, on-the-fly checking (including type inference and checking, which is huge), and pretty good completion. All of this seems to "just work".
The build system also seems to "just work" and utop is pretty nice.
* 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.
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.
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.
All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing.
All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior.
For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes.
You gotta admit there's something just really awesome about that.
But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.
Not sure how it came to be that everyone totally ignores it.
Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction.
OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic.
> Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.
I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway.
I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.
I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue.
You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time.
> modular implicits would be a game changer for OCaml.
They would be very nice!
In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary.
This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.
Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast.
Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users tend to be a lot more oriented towards practical matters like, you know, building softwares rather than lenses library.
> Being lazy by default makes it very difficult to reason about Haskell performance really fast.
I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.
> practical matters like, you know, building softwares rather than lenses library.
This is the classic completely idiotic "haskell isn't practical" argument. Let me tell you what's not practical: not having multithreading. Not having a well-functioning asynchronous programming system (Async sucks).
Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
It's not persecution. It's just that recently you can't have a discussion about OCaml without having an Haskell devotee dropping by and implying you should use Haskell instead generally for somewhat spurious reasons (same with Rust but the languages are so different, it's easier to ignore). It gets a bit tiring.
> think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.
We might have to agree to disagree on this one.
> Not having a well-functioning asynchronous programming system (Async sucks).
It's a chance everyone uses Lwt then. Pretty much no one uses Async apart from Jane Street.
> Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.
OCaml has multiple lenses libraries including one written by Jane Street which are not used a lot because mutations are fine. This is not being far behind. It is being practical.
It is also true that the standard library is growing faster recently, so maybe this will become less of a problem I. The future.
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-...
* https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html
I don't see Rust being the best option for anything other than low level systems code.
My point was more that I think OCaml competes mostly with other functional and more generally GCed languages, not a language like Rust.
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.
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.