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...
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/moby?utf8=%E2%9C%93&q=&type=&language=oca...
[3] https://discuss.ocaml.org/t/multicore-ocaml-january-2020-upd...
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.
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.