Congratulations to the team and hope ML family languages become popular and mainstream.
Rust compiler front-end was initially written in OCaml and later moved to rust and dependent on LLVM written in C++. Still Rust became more popular by following a simple imperative style of programming with some incremental improvements over C/C++.
OCaml is confined mostly within Facebook with some use by Bloomberg and in Xen development. I hope functional programming languages become popular and also used for systems programming. OCaml indeed is used for system programming, like Mirage unikernel OS is written in it.
Although OCaml can offer whatever is offered by Rust I believe Rust being imperative language along the lines of C++ will be more popular.
Having coded a lot in both OCaml (I used to lead OCaml Batteries Included) and Rust (I'm a contributor to the Rust compiler and stdlib), I believe that they have very different targets.
Rust is really, really good at systems-level programming, it has great concurrency, but closures are more restricted than OCaml and it doesn't have general garbage-collection.
OCaml shines to implement really complicated algorithms. Anything that requires symbolic manipulation/pattern-matching, for instance, or manipulating large graphs, or maintaining extremely complex invariants. Garbage-collection that just works is invaluable but it doesn't play nicely with multicore yet.
In other words, I believe that there's room for both in our world! I could see myself developing applications in which some components are implemented in Rust and others in OCaml.
Depends on what you're trying to do. I've never found it to be a limitation but I don't do anything terribly intricate. Just web dev for work, and I wrote a toy language parser and type inferencer in it. There are maybe three lines of code that GADTs might have let me avoid casting in the type inferencer, but oh well. Different use cases that use GADTs to a greater extent, of course, you might miss them. What is your use case, and how much are you reliant on GADTs in your existing daily life?
I’ve used F# and USING it feels very similar to OCaml in all of the important ways.
The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it.
Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it.
For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc
If you are in the .NET world, then definitely prefer F# to C#. However be aware that it differs in some significant ways from OCaml. E.g., it does not have a separate module language (module types, functors, first-class modules). Its design is in a different, more object-oriented direction, with support for classes and interfaces.
Basically, if you do use F#, be aware that it has its own idioms that you must learn; it's not a drop-in replacement for e.g. OCaml/Haskell/etc.
In no particular order:
- significant whitespace and no `let ... in` which makes for a more streamlined syntax
- no +. vs +
- a solid standard library
- much improved tooling (see the ionide plugin for vscode)
- you can use all the .Net libraries
- multicore support
- list comprehension and iterators
- object support with a minimalistic syntax
(I don't include type providers as I never had proper use cases for them)
All of those either remove pain points (some of them arguably very small) or introduce improvements that are sensible in day to day life.
With that and the fast that Ocaml and F# can (for the most part) easily be transpiled into one another, nowadays I see very little reason not to use F#.
That being said, I find the fact that you basically never need explicit types in Ocaml very elegant (in F# the uniform syntax mean that you will need occasional types hints to disambiguate operations).
Its true that you can't literaly transpile very high order things such as GADT but the was majority of code is trivial to translate as both syntax and available constructs match.
I practice, I found translations between the two languages to be fairly easy (the same cannot be said for most language pairs).
(I was not aware of the new let-syntax, thats a nice addition (although computation expression did not make my list as they are more of an enabler for library authors than normal users). I will dig in to see what people build around it...)
Oh cool, I'd forgotten F# had those (or maybe it got them recently?).
> Its true that you can't literaly transpile very high order things such as GADT but the was majority of code is trivial to translate
Would still have to disagree there; OCaml code heavily relies on modules/module types/functors, while F# code relies more on classes. In practice these are not trivially translateable.
> I will dig in to see what people build around it...
I was mentionning manually translating a code base from one language to the other. I am not aware of a tool to do that (which, as others have said, would be tricky to do automatically for some constructs).
- both polymorphic variants and GADTs are extremely powerful mechanisms to let you keep track of invariants, in a manner that cannot be replicated readably in Rust so far;
- OCaml's pattern-matching is a bit more flexible than Rust's ;
- (thanks to the GC) OCaml's closures are much more flexible than Rust closures;
- I guess OCaml's blindingly fast exceptions can be useful for some algorithms, although I haven't really experienced the need for them myself.
Again, that's not to say that Rust doesn't have great stuff for it (affine types 4eva!) or that OCaml doesn't have its own limitations – Rust is currently my main language and I do not regret it.
But there are some algorithms that I really don't want to write in Rust. Recently, for instance, I stumbled upon this: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... . Trivial algorithm, trivial to write in OCaml, feasible but much less straightforward in Rust.
Jane Street also is a regular contributor and a heavily uses OCaml for their infrastructure and trading systems too. They have very technical blogs about how they use OCaml which is very interesting. [0]
Not only these, but I also recently noticed OCaml-written parts of Moby[1]. Another significant example is Tezos[2]. So far, OCaml became much more modern and usable in the last couple of years. The biggest missing parts are multicore[3] and solving the metaprogramming issues[4]. Both are being worked on, and, hopefully, will be ready in a couple years.
I believe OCaml is the main language in Jane Streets tech stack rather than just being used for dev tools like Infer. I saw they were hiring compiler engineers recently so, assuming this is for OCaml, they are pretty deep into the language.
They are very involved with the ecosystem. They sponser a lot of the events, conferences, etc. In fact I'm attending OPLSS this year and even that is sponsered by them.
I even saw someone compare OCaml build methods as 'Jane Street Way' vs 'Other Ways'. It's hard to ignore such an influential company like that when the question about who uses them comes up!
how on earth is this gatekeeping? GP said nothing like "imperative programming isn't true programming and deserves to be looked down upon" or w/e, they just expressed a personal preference for FP. ("I hope functional programming languages become popular and also used for systems programming.")
> Some preliminary runtime work for OCaml multicore
Anyone have more information on a likely time-line for multicore? It feels like it's been comming for a long time. I suppose it's encouraging that some work is released in the mainline compiler though.
Behind the scenes there's a lot of work happening. Retrofitting parallelism to an existing runtime while maintaining compatibility with existing code and keeping the kind of performance users are used to is difficult.
There will be a lot more information out in the next month or two about how it all works, which should coincide with getting more of it upstream.
I don't speak for OCaml or OCaml Labs but am a contributor to multicore if people have specific questions, I can try to answer them.
What are the top challenges? Why is it taking so long? What exactly will multicore OCaml cover? Native OS threads? Green threads? Actors like in Erlang/Elixir?
I'm learning Rust and I'm doing so a bit begrudgingly at times. I like OCaml better but the lack of frictionless parallelism is a huge letdown. (And I don't think spawning several processes is an actual alternative, no.)
Trust me, there is some amount of programmers out there who will very quickly adopt OCaml after it gains multicore abilities. They are eagerly awaiting and watching. And I'm one of them.
Mostly the work is slowly getting it upstream in a way that doesn't break existing code. (There are some changes which affect C extensions, although the changes so far have only had a very minor impact, things like fixing const-correctness).
I'm reasonably competent in Haskell and am interested in checking out OCaml. Can anyone recommend any good resources (books, tutorials, etc.) for someone like me to get started?
Based on the introduction, that looks like a great book which I definitely wouldn't have found on my own, so thanks for the suggestion! I'll have to give it a try when I have some time.
Sometime in the future I would like to use ocaml, but I found the user experience from 0 so difficult that I just didn't bother at all. Haskell was much friendlier.
Tooling mostly. It was needlessly difficult to make a small project and use dune to build and run it.
Contrast this with Elixir and Rust where the beginner howtos are front and center. Both mix and cargo are amazing tools that are also very easy to use. Dune is rather cryptic and non-obvious.
I'd definitely be much more excited about OCaml if dune and opam had good cheatsheets and proper brief manuals that don't assume anything about the proficiency of the reader.
A lot of educational OCaml material is either old or imprecise.
Again, start with dune. I want a brain-dead intro to it but still it should cover everything it can do, and how.
Thank you for posting these. I've lost some of the links and I am now bookmarking them so I don't lose them again.
I got through some of them and I felt the quality of the OCaml teaching material itself is very high. No remarks there. Any syntax cognitive shock is eventually overcome and things flow pretty well.
Wasn't `oasis` the legacy way of building projects? Thought everyone used `dune` now?
In short, I am looking for the way that most OCaml programmers manage their project nowadays. I know this is happening through `dune` but the tool's documentation and educational material is very lacking. I don't object against the build file being LISP; when I thought about it for a minute it actually makes a lot of sense.
But I need a quality material on everything you can do with `dune`. Can you recommend such?
> Wasn't `oasis` the legacy way of building projects? Thought everyone used `dune` now?
Yeah, I believe new projects tend to use dune, and some older projects have switched from OASIS to dune. I personally still use OASIS mainly due to laziness. :D
> But I need a quality material on everything you can do with `dune`. Can you recommend such?
I have not used dune myself, but a quick glance at these sites suggests that they may be quite useful:
As I mentioned in a sibling comment, last time I seriously attempted getting more into OCaml has been at least half a year ago. I either didn't find some of those materials or they have been improved in the meantime.
Whatever the case, I can see clearly now that I was wrong about the poor quality of the dune and opam teaching material.
I apologise for that. And I'll be making a comeback to OCaml. I mean, it still has roadblocks but they are easier to overcome when tooling is handled (minus the lack of the multicore support but fingers crossed that that's coming soon).
I think the documentation would benefit from suggesting the use of the `dune init ...` commands for beginners - ideally somewhere on the github readme or the readthedocs quickstart.
When starting out with OCaml, as I was more accustomed to makefiles, the process of setting up dune projects was a major hurdle. I later found the init commands while looking through the man pages, and was surprised it wasn't more clearly mentioned in the project documentation.
It has been a while. I admit I haven't read the entire tutorial and I checked the website just now -- seems like stuff has been added (and maybe modified). Looks a bit more understandable and beginner-friendly now! I'll have to give my two hobby projects another go from scratch. :)
Is it OK for me to hit you up on OCaml's Discourse forum if I need help or want to give extra feedback when I am able to, in the future?
For me it was very difficult to setup/understand/use the following: build tools, dependency management, installing and using libraries, installing and using a specific library for working with unicode strings ("Camomille"), working with strings themselves, etc. I spent a couple of evenings on that and gave up because I just wasn't getting anywhere.
If you need a regex that complicated it’s probably better to be written as a parser. Not only will it be way more performant, it will be much more maintainable.
I agree that if you're designing a system from scratch this makes sense. Ocassionally you need to extend the syntax of an existing system that is written with regular expressions and would require a negative lookahead. Some sub-parser with negative lookahead functionality would be possible, but a regex would be more convenient in a pinch.
Rust compiler front-end was initially written in OCaml and later moved to rust and dependent on LLVM written in C++. Still Rust became more popular by following a simple imperative style of programming with some incremental improvements over C/C++.
OCaml is confined mostly within Facebook with some use by Bloomberg and in Xen development. I hope functional programming languages become popular and also used for systems programming. OCaml indeed is used for system programming, like Mirage unikernel OS is written in it.
Although OCaml can offer whatever is offered by Rust I believe Rust being imperative language along the lines of C++ will be more popular.
Rust is really, really good at systems-level programming, it has great concurrency, but closures are more restricted than OCaml and it doesn't have general garbage-collection.
OCaml shines to implement really complicated algorithms. Anything that requires symbolic manipulation/pattern-matching, for instance, or manipulating large graphs, or maintaining extremely complex invariants. Garbage-collection that just works is invaluable but it doesn't play nicely with multicore yet.
In other words, I believe that there's room for both in our world! I could see myself developing applications in which some components are implemented in Rust and others in OCaml.
We use it in production at Olo, and I used it in production at my last company.
Since learning F#, languages where if statements aren't expressions and that don't have option types feel broken to me =)
The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it.
Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it.
For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc
Basically, if you do use F#, be aware that it has its own idioms that you must learn; it's not a drop-in replacement for e.g. OCaml/Haskell/etc.
The syntax is very similar but it solves many of Ocaml's pain points and you will get better tooling and more libraries thanks to .Net.
All of those either remove pain points (some of them arguably very small) or introduce improvements that are sensible in day to day life.
With that and the fast that Ocaml and F# can (for the most part) easily be transpiled into one another, nowadays I see very little reason not to use F#.
That being said, I find the fact that you basically never need explicit types in Ocaml very elegant (in F# the uniform syntax mean that you will need occasional types hints to disambiguate operations).
Are you referring to F#'s computation expressions? If so, OCaml has a similar-in-power let-syntax now: http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s...
> Ocaml and F# can (for the most part) easily be transpiled into one another,
Actually they can't. They are quite different languages in practice.
Its true that you can't literaly transpile very high order things such as GADT but the was majority of code is trivial to translate as both syntax and available constructs match.
I practice, I found translations between the two languages to be fairly easy (the same cannot be said for most language pairs).
(I was not aware of the new let-syntax, thats a nice addition (although computation expression did not make my list as they are more of an enabler for library authors than normal users). I will dig in to see what people build around it...)
Oh cool, I'd forgotten F# had those (or maybe it got them recently?).
> Its true that you can't literaly transpile very high order things such as GADT but the was majority of code is trivial to translate
Would still have to disagree there; OCaml code heavily relies on modules/module types/functors, while F# code relies more on classes. In practice these are not trivially translateable.
> I will dig in to see what people build around it...
The major thing is getting an async/await-like syntax for concurrent operations. Super useful for literally everyone. E.g. my project https://github.com/yawaramin/re-web/blob/eb7ce8474d34c60f9f9...
Here are a few others:
- both polymorphic variants and GADTs are extremely powerful mechanisms to let you keep track of invariants, in a manner that cannot be replicated readably in Rust so far;
- OCaml's pattern-matching is a bit more flexible than Rust's ;
- (thanks to the GC) OCaml's closures are much more flexible than Rust closures;
- I guess OCaml's blindingly fast exceptions can be useful for some algorithms, although I haven't really experienced the need for them myself.
Again, that's not to say that Rust doesn't have great stuff for it (affine types 4eva!) or that OCaml doesn't have its own limitations – Rust is currently my main language and I do not regret it.
But there are some algorithms that I really don't want to write in Rust. Recently, for instance, I stumbled upon this: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... . Trivial algorithm, trivial to write in OCaml, feasible but much less straightforward in Rust.
https://concurrencyfreaks.blogspot.com/2017/08/why-is-memory...
[0] https://blog.janestreet.com/
My absolute favorite OCaml program is Unison [1], which is a cross-platform performant file watcher and sync tool.
It's essential to a good VM or remote development experience, and the the principal technology behind docker-sync. (Mac users will thank me.)
[1] https://github.com/bcpierce00/unison
[2] http://docker-sync.io/
[1] https://github.com/moby?utf8=%E2%9C%93&q=&type=&language=oca...
[2] https://tezos.com/
[3] https://discuss.ocaml.org/t/multicore-ocaml-january-2020-upd...
[4] https://discuss.ocaml.org/t/the-future-of-ppx/3766
They have some awesome talks on YouTube as well.
https://www.janestreet.com/programming/
Yaron Minsky introduced OCaml into Jane Street almost 20 years ago:
https://blog.janestreet.com/author/yminsky/
He’s working on a new version of his book: http://dev.realworldocaml.org/
I even saw someone compare OCaml build methods as 'Jane Street Way' vs 'Other Ways'. It's hard to ignore such an influential company like that when the question about who uses them comes up!
"Still", as if non-pure functional languages are not worth it or "bad", even if just depending on a project that uses them.
Sorry, but that gatekeeping attitude among functional languages proponents is very tiring.
Anyone have more information on a likely time-line for multicore? It feels like it's been comming for a long time. I suppose it's encouraging that some work is released in the mainline compiler though.
Behind the scenes there's a lot of work happening. Retrofitting parallelism to an existing runtime while maintaining compatibility with existing code and keeping the kind of performance users are used to is difficult.
There will be a lot more information out in the next month or two about how it all works, which should coincide with getting more of it upstream.
I don't speak for OCaml or OCaml Labs but am a contributor to multicore if people have specific questions, I can try to answer them.
I'm learning Rust and I'm doing so a bit begrudgingly at times. I like OCaml better but the lack of frictionless parallelism is a huge letdown. (And I don't think spawning several processes is an actual alternative, no.)
Trust me, there is some amount of programmers out there who will very quickly adopt OCaml after it gains multicore abilities. They are eagerly awaiting and watching. And I'm one of them.
Mostly the work is slowly getting it upstream in a way that doesn't break existing code. (There are some changes which affect C extensions, although the changes so far have only had a very minor impact, things like fixing const-correctness).
I like Exercism for coding exercises that have runnable test cases: https://exercism.io/tracks/ocaml
https://caml.inria.fr/pub/docs/oreilly-book/html/index.html
https://caml.inria.fr/pub/docs/u3-ocaml/
https://ocaml.github.io/ocamlunix/
The other posters mentioned good books already. Another resource is Emacs + merlin, it really is magic when working with ocaml.
Contrast this with Elixir and Rust where the beginner howtos are front and center. Both mix and cargo are amazing tools that are also very easy to use. Dune is rather cryptic and non-obvious.
I'd definitely be much more excited about OCaml if dune and opam had good cheatsheets and proper brief manuals that don't assume anything about the proficiency of the reader.
A lot of educational OCaml material is either old or imprecise.
Again, start with dune. I want a brain-dead intro to it but still it should cover everything it can do, and how.
You could give https://ocaml.org/learn/tutorials/ a try as well, specifically this: https://ocaml.org/learn/tutorials/setting_up_with_oasis.html
For profiling: https://ocaml.org/learn/tutorials/performance_and_profiling....
For debugging: https://ocaml.org/learn/tutorials/debug.html and https://caml.inria.fr/pub/docs/manual-ocaml/debugger.html
For unit testing: https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/da... and https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/te...
You may find https://github.com/gildor478/ounit#examples useful for both OUnit (unit testing) and OASIS (build system).
I got through some of them and I felt the quality of the OCaml teaching material itself is very high. No remarks there. Any syntax cognitive shock is eventually overcome and things flow pretty well.
Wasn't `oasis` the legacy way of building projects? Thought everyone used `dune` now?
In short, I am looking for the way that most OCaml programmers manage their project nowadays. I know this is happening through `dune` but the tool's documentation and educational material is very lacking. I don't object against the build file being LISP; when I thought about it for a minute it actually makes a lot of sense.
But I need a quality material on everything you can do with `dune`. Can you recommend such?
Yeah, I believe new projects tend to use dune, and some older projects have switched from OASIS to dune. I personally still use OASIS mainly due to laziness. :D
> But I need a quality material on everything you can do with `dune`. Can you recommend such?
I have not used dune myself, but a quick glance at these sites suggests that they may be quite useful:
- https://dune.build/
- https://dune.build/examples
- https://dune.readthedocs.io/en/stable/
- https://github.com/ocaml/dune/blob/master/doc/quick-start.rs...
- https://github.com/ocaml/dune/tree/master/example
- https://ocamlverse.github.io/content/quickstart_ocaml_projec...
- https://medium.com/@bobbypriambodo/starting-an-ocaml-app-pro...
For opam:
- https://opam.ocaml.org/doc/FAQ.html
- https://opam.ocaml.org/doc/Packaging.html
- https://opam.ocaml.org/doc/Manual.html
- https://github.com/ocaml/opam/tree/master/tests/packages
I hope this helps.
As I mentioned in a sibling comment, last time I seriously attempted getting more into OCaml has been at least half a year ago. I either didn't find some of those materials or they have been improved in the meantime.
Whatever the case, I can see clearly now that I was wrong about the poor quality of the dune and opam teaching material.
I apologise for that. And I'll be making a comeback to OCaml. I mean, it still has roadblocks but they are easier to overcome when tooling is handled (minus the lack of the multicore support but fingers crossed that that's coming soon).
When starting out with OCaml, as I was more accustomed to makefiles, the process of setting up dune projects was a major hurdle. I later found the init commands while looking through the man pages, and was surprised it wasn't more clearly mentioned in the project documentation.
Is it OK for me to hit you up on OCaml's Discourse forum if I need help or want to give extra feedback when I am able to, in the future?
On top of that Dune has some cross-compilation features.
https://dune.readthedocs.io/en/latest/cross-compilation.html
...the question seems moot to me.