
Why We Use OCaml - ALee
http://tech.esper.com/2014/07/15/why-we-use-ocaml/
======
ALee
Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding
the business case for OCaml and I think it'd be helpful to write here:

1) It's practical - for our team, we had developed in it before and had
deployed a large system in it - we could get to where we wanted quickly.

2) we think it's a competitive advantage (see OP and PG's Beating the Averages
essay) - additionally, since we deal with large amounts of data, OCaml was
particularly helpful in that regard too

3) OCaml is a good filter - the thing that matters more to us is a person's
elasticity of learning - their ability to learn new things. We use the right
tool for the right job, so we also use javascript, java, objective-C, etc.
OCaml is a pretty good filter and test for elasticity of learning.

Lastly, not a primary reason, but an advantage - languages get popular because
the companies that use them are popular (i.e. gain market traction and can pay
developers). That doesn't mean it's the most efficient way to get things done.
We'd like to be part of the group that helps make the industry more efficient.

~~~
talder
How do you feel about the fact that OCaml has no capacity for "real"
multithreading? It seems that such capability will only become more important
in the future.

~~~
judk
Is it obvious that you need threads instead of CSP ?

------
claudiusd
> OCaml includes many features that are not available in the more mainstream
> programming languages ... and we believe this gives us a competitive
> advantage. ... The purpose of this post is to explain the benefits of OCaml
> and compare it to other languages. We hope to convince readers, especially
> other developers, to consider adopting OCaml for their projects as well.

The authors did a great job explaining the benefits of OCaml and why I as a
developer should think about using the language. I actually want to play
around with it now in a side project.

As a start-up manager though, I think the business case is strongly against
them and don't believe there is any "competitive advantage" from using
OCaml... in fact, I think the opposite. Here's why:

* There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages. * OCaml is hard (and so are most functional programming languages). You will always need exceptionally talented developers to work on your code base and that will get expensive. * OCaml is not popular. You will have to pay an additional premium for OCaml developers due to the lack of experienced talent. * OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster? I don't know. Will Ruby-on-Rails? Yes. I'd pick RoR any day just to eliminate the risk of getting to market late.

~~~
avsm
While your mileage will vary depending on the nature of your startup, I can
point you to a paper we wrote summarising our experiences using OCaml to build
the XenServer toolstack in a startup environment [1].

You should bear in mind that OCaml represents almost _twenty_ years of
continuous development (see the history chapter in Real World OCaml [2]), with
a community steeped in some of the most cutting edge technology in modern
programming languages (e.g. the Coq theorem prover or the CompCert certified C
compiler).

I was the startup manager at XenSource that took the risk, and all of your
points were not true for us:

\- by joining the Caml Consortium (very cheap), we got access to the core
developers and a yearly face-to-face. We're talking about Xavier Leroy and
Damien Doligez here. Do you get that with Java?

\- the compiler and runtime are utterly rock solid and engineered for a modern
Unix environment. We found more serious gcc bugs (5+) than OCaml bugs (one, to
do with compiling functions with >32 arguments, and was already fixed in trunk
and a backport available inside a day).

\- Hiring OCaml developers gave us the cream of the crop even for entry level
jobs, and I work with several of the original team that we assembled to this
day. See the paper [1] for details on several of the responses from within the
company and how we responded.

\- The OCaml community is very pragmatic, since the language is used in quite
a few large codebases like Coq, CompCert, Why3, XenServer, Pfff (Facebook) as
well as closed-source codebases such as Jane Street and Lexifi's. Most
language evolution discussions are evaluated against these large users. I
consider OCaml rather unique in that, despite being a small community, the
ones that do use it do so seriously and often at scale.

I find it amusing that so-called "risk-averse" startup managers discount a
20-year old language with legendary stability in favour of relatively new
languages. Nothing beats having developers that deeply understand their
language and libraries, and that's only imparted with age and stability.

I would also note that being based in Cambridge, it's quite easy to grads that
know ML (and the same is true in many US universities that teach OCaml, like
Cornell, Harvard, Princeton and Yale).

[1] [http://anil.recoil.org/papers/2010-icfp-
xen.pdf](http://anil.recoil.org/papers/2010-icfp-xen.pdf)

[2]
[https://realworldocaml.org/v1/en/html/prologue.html#a-brief-...](https://realworldocaml.org/v1/en/html/prologue.html#a-brief-
history-from-the-1960s)

~~~
dragonwriter
> I find it amusing that so-called "risk-averse" startup managers discount a
> 20-year old language with legendary stability in favour of relatively new
> languages.

While I mostly agree with your post, the four languages mentioned as opposed
to OCaml in the grandparent post (Ruby, Python, Javascript, and Java) are all
older than OCaml (which is 18 years old) -- Java, JavaScript, and Ruby are all
19 years old, and Python is 23 -- so they aren't "relatively new languages"
compared to OCaml.

~~~
innguest
20 years for language X do not bring the same amount of benefits as 20 years
for language Y, as can be clearly seen if we compare Javascript and OCaml.

~~~
gnuvince
Not sure which language looks better here... I'd say that even with its
greater popularity, JavaScript is worse in pretty much every aspect than
OCaml.

~~~
innguest
Yes, I meant OCaml looks better, in light of all the javascript traps.

------
kenko
From the "About" page: "We want to see a world where everyone gets the mental
luxury of an assistant, including the assistant. We are making this future
happen. [...] Oh, did we mention every team member gets an assistant?"

So ... there's some kind of cycle of assistants, where X is my assistant, Y is
X's assistant, and I'm Y's assistant? Esper currently employs infinity people?
Assistants are employees but not, you know, _team members_?

~~~
S4M
The assistants mentioned in the About page are electronic, not real persons,
and I suppose that it's the product Esper is building. I'm not affiliated with
them in any way but I like the concept.

------
vvijay03
Good read. I really liked how the author concretely defined the things they
use in OCaml, instead of just saying "functional programming" and waving their
hands.

~~~
andrewflnr
"Algebraic data types!" [waves hands vigorously]. Seriously though, I agree.
It's a very solid run-down of all the main ways OCaml is cool. I'll probably
link people here if they ask my about why they should bother with OCaml.

------
eridius
Interesting list. I'm curious if the author has looked at Rust and how they
think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an
identical feature list, but it seems to me to perhaps be a lot more practical
for a lot of work than OCaml (largely because Rust can basically be used
anywhere C++ can be, and it has good support for C FFI).

~~~
dbpatterson
I think that, having used both of them, Rust is going to feel a lot lower
level than OCaml. The single biggest thing is that it's pretty hard (slash
near impossible) to write Rust code without thinking about memory allocation,
which adds non-trivial mental overhead to the work. That isn't to put down
Rust - I think they are the first language that actually has a static, type-
checkable story about memory allocation, and that's phenomenal, _but_, the
reason for this is to be able to write soft-realtime code (for example,
browser engines, games, etc). Web code, at least in the early stages, probably
usually has lower performance requirements, and most people would probably
trade some performance (and I don't mean to say that OCaml is slow, anymore
than Go is slow, etc) for not having to even think about that stuff.

~~~
eridius
Eh, I don't see that as a downside. And actually, I'm not sure that's even
true. It's already apparent that a lot of people are using a lot of completely
unnecessary allocation in Rust, precisely because they aren't thinking about
what they're doing (and so are doing things like using heap-allocated String
objects when they really just need &str slices, or using Box unnecessarily;
this was one of the reason cited for moving away from the ~ sigil, as it was
considered to "hide" allocation too much).

And speaking personally, I almost never have to consciously think about
allocation, unless I'm doing really performance-sensitive work. The
straightforward approach is usually correct.

------
roryokane
For a more in-depth list of reasons to use OCaml, I recommend “OCaml: What You
Gain” at [http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-
gain...](http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/).

It is part of the series of posts linked in “Python to OCaml: Retrospective”
at [http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-
ret...](http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-
retrospective/) (HN story:
[https://news.ycombinator.com/item?id=7858276](https://news.ycombinator.com/item?id=7858276)).
I learned a lot about OCaml from that series of posts.

For more comparisons between OCaml and other langages, see the first two posts
in the series. In the first post,
[http://roscidus.com/blog/blog/2013/06/09/choosing-a-
python-r...](http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-
replacement-for-0install/), the author compares OCaml to many languages,
including Python, Go, and Haskell. The second post
[http://roscidus.com/blog/blog/2013/06/20/replacing-python-
ro...](http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/)
summarizes his conclusions about the languages – he decided that either
Haskell or OCaml would meet his needs best. (He chose OCaml after that,
obviously.)

------
_random_
A bit surprised F# was not even mentioned. I guess they are hardcore meta-
programming users?

~~~
jonsterling
F# is an ML without any of the things which make ML good (modularity). It's a
breath of fresh air if you're on a Microsoft platform, but if you can use
OCaml, it is superior.

~~~
JamesBarney
Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to
know a little more about what specifically F# lacks that makes OCAML superior.
I want to know what I'm missing out on.

~~~
Dn_Ab
_Where Ocaml is better_ :

\- Single Core Speed (Ocaml is fast)

\- native compilation without requiring some installed runtime

\- Polymorphic Variants (Last I read, to be used only when regular variants
are not sufficient)

\- Modules and Functors (there's a proof of principle for F# supporting these)

\- GADTs (allow for richer more expressive types, much more flexibility than
regular algebraic data types)

\- camlp4

\- more pervasive structural typing, higher kinded types...type system is not
weighted down by a foreign runtime

 _Where F# is better_ :

\- better support for not-sequential programming in all its forms: actors with
lightweight threads, parallel, async, gpu (many production ready choices),
reducers (and Go style channels if they accept joinads)

\- Active Patterns are a dark horse

\- Type Providers are curious. They seem like dumbed down metaprogramming at
first but it's one of those cases where constraints benefit creativity.
Although you could certainly do what they provide (and more easily at times)
with metaprogramming, I've never seen metaprogramming used that way before.
And especially with the proliferation of APIs, stuff like json inference makes
going to a language without them like going from 3 monitors to one.

\- Units of Measure

\- More libraries and Better cross platform support via Xamarin and unity3d

\- #light. F# syntax is a tiny bit cleaner and surprisingly close to Python at
times.

\- Computation expressions/do notation are not quite monads and can be more
flexible. Tomas Petricek argues the case here:
[http://tomasp.net/blog/2013/computation-zoo-
padl/](http://tomasp.net/blog/2013/computation-zoo-padl/)

Why the above do not matter: The MLs tend to be more pragmatically focused
than other functional languages and espouse using as little fancy code as
possible. The core of both languages are the same, so much of the time and
ignoring library choices, you won't be seeing many differences between F# and
OCaml. It's more like Portuguese vs Spanish than English vs German.

~~~
barkmadley
I'm surprised you mention camlp4 as an advantage over F#. It is being removed
from the official distribution due to the problems that it causes[1], to be
replaced with extension points[2].

We use camlp4 a bit at Red Lizard Software and we are eagerly looking to move
to extension points as soon as they are released.

[1]: [https://blogs.janestreet.com/ocaml-4-02-everything-
else/](https://blogs.janestreet.com/ocaml-4-02-everything-else/) [2]:
[https://blogs.janestreet.com/extension-points-or-how-
ocaml-i...](https://blogs.janestreet.com/extension-points-or-how-ocaml-is-
becoming-more-like-lisp/)

------
toby
What are some advantages of OCaml over Haskell?

~~~
seliopou
I've used Haskell to build JavaScript tools and analyses[0], among other
things[1], and have been using OCaml for the past nine months to develop a
software-defined networking controller called frenetic[2]. Off the top of my
head, here are a few areas where OCaml has an edge on Haskell:

1\. The module system. OCaml's module system is a language in and of itself.
It not only allows you to define modules that export certain identifiers and
types, it also allows you to write functors, which are essentially functions
in the module language that can take a module as an argument and produce a new
module as a result. This is a great way of reusing code in a project as well
as defining external APIs in a general but natural way. OCaml's module system
the closest I've seen to realizing the dream of building software by taking
some modules from here or there and composing them together.

2\. Mutation. Unlike Haskell, OCaml allows mutation. Specifically, OCaml
allows value mutation in certain contexts, while both Haskell and OCaml do not
allow variable mutation. What this means is that in both languages, if you
have an identifier, you cannot change the value that the identifier points to;
you can only shadow the identifier with a new binding. But in OCaml, you can
declare certain fields of your types to be mutable. You can also wrap values
in a "box" which allows you get the same feel that you would out of variable
mutation. While in general it's a good idea to limit your use of mutation,
sometimes you know it's ok and you just want to do it. OCaml lets you do that,
but it requires you to be explicit about it rather than just letting you do it
willy-nilly.

3\. gdb-able. If you know how to use gdb (and even valgrind I believe), you
can use it to debug your OCaml programs. If you try and use these tools with
Haskell, you will get nothing but nonsense until you learn how to read the
matrix. This fact by itself for some people will make OCaml a candidate for
systems programming over Haskell.

4\. Subtyping. Certain features of OCaml's type system allow you to do
subtyping, complete with type variable annotations to indicate covariance or
contravariance. This is a feature that Haskell's type system does not have, so
in a sense this is a strength of OCaml. However in my experience, this feature
of the type system is hard to use and reason about, and I've seen little
(maybe no?) code in the wild that takes advantage of it, with the exception of
some simple inference the type system can do in this respect related to
polymorphic variants[3].

All that being said, Haskell's still my hobby language of choice. But for
building real systems, I'm warming to idea of OCaml as a viable candidate
language.

[0]:
[http://www.cs.brown.edu/research/plt/dl/adsafety/v1/](http://www.cs.brown.edu/research/plt/dl/adsafety/v1/)

[1]: [https://github.com/seliopou/typo](https://github.com/seliopou/typo)

[2]: [https://github.com/frenetic-lang/frenetic](https://github.com/frenetic-
lang/frenetic)

[3]:
[https://realworldocaml.org/v1/en/html/variants.html#polymorp...](https://realworldocaml.org/v1/en/html/variants.html#polymorphic-
variants)

~~~
runT1ME
Neat reply, thanks.

In regards to #2, this sounds like the ST monad, are they comparable at all?

What makes OCaml easier to debug with GDB opposed to haskell specifically? I
don't have experience doing either, but that's a curious statement, I would
have assumed they were similar (both native code w/ some sort of GC...)

~~~
tel
OCaml allows you to use mutation pervasively without marking your type.
Haskell requires you mark your type with `IO`, `ST`, `State`. You can see
Haskell as advantageous because it means that if you have a type without one
of those markers you can be certain there is no observable mutation occurring.
You can also see Haskell as disadvantageous because those markers are a little
annoying.

The ST monad lets you transition from regions which allow mutation to pure
regions and then back again.

~~~
dllthomas
Basically, all OCaml code runs in IO. You can still only modify things that
you've marked as modifiable (analogous to an IORef), but there is no
constraint on where you can modify them from.

(In case it's unclear, I'm agreeing with tel and rephrasing.)

~~~
orbifold
One advantage that gives you, is that you can easily define a monad on top of
that and not worry about monad transformers. Jane Streets async library does
that in its Deferred module [https://ocaml.janestreet.com/ocaml-
core/111.17.00/doc/async/...](https://ocaml.janestreet.com/ocaml-
core/111.17.00/doc/async/#Std.Deferred)

~~~
tel
But I _like_ transformers... a lot!

------
skrebbel
I think the HTML example in the blog post is _excellent_. It's a real,
recognizable problem, and the solution is simple and concise.

Many FP blog posts get too fundamental/abstract at this stuff, but here it
really shows how static typing and pattern matching makes something very
simple that is much more involved in e.g. Python or C#.

------
IvarTJ
Could someone comment on what instances you would typically apply lambdas and
closures in real-world code?

I figure that they are at least more convenient than callbacks with a
*userData parameter like in C.

~~~
zem
the "with-" pattern (originally from lisp, i believe, but ruby did a lot to
bring it to the masses), where something like a filehandle manages its own
lifecycle, and calls your closure in between. so rather than the C-like

    
    
        let f = open-file-for-writing(filename);  
        for line in array {  
          write-line-to-file(f, line);
        }
        close-file(f);
    

you can do

    
    
        with-open-file-for-writing(filename) {|f|
          for line in array {
            write-line-to-file(f, line);
          }
        }
    

where the definition of with-open-file-for-writing() would look like

    
    
        def with-open-file-for-writing(filename, closure) {
          let f = open-file-for-writing(filename);
          call-closure(closure, f);
          close-file(f);
        }
    

the benefit of having this be a closure rather than just a function pointer
can be seen in the write array to file example above, where the "array"
variable is in the scope of the calling function, but when with-open-file-for-
writing calls your closure it can make full use of its own local variables.

~~~
dllthomas
Of course, you can build your own closure:

    
    
        void do_stuff_with_file(struct relevant_data *, FILE *);
    
        ...
    
        {
            struct relevant_data data = { ... }
            with_open_file_for_writing(do_stuff_with_file, data, filename);
    
        }
    
    

IMO, the _biggest_ downside there being how far it typically pushes the
definition of that function from the call site. Small functions - a good
practice anyway - ameliorates that a bit.

~~~
zem
you can, but it's sufficiently clunky that it simply doesn't feel like a
natural thing to do in the language. good language design is a lot more about
the things it makes easy and natural than the things it makes possible.

~~~
dllthomas
_" you can, but it's sufficiently clunky that it simply doesn't feel like a
natural thing to do in the language."_

It does to me, but I've done enough functional programming that I easily reach
for concepts from that space.

 _" good language design is a lot more about the things it makes easy and
natural than the things it makes possible."_

Of course. I don't know where you got the idea I was saying closures aren't a
good thing to have language support for. I said precisely the opposite.

------
candl
They mention they use Ocaml for server-side tasks. Is there a popular solution
in OCaml for writing web pages or rest apis?

~~~
hbbio
You can have a look at

[http://github.com/MLstate/opalang](http://github.com/MLstate/opalang)

------
advocaat23
Cool tech, but ...

I went to the About-Page and I got the following message out of it:

"We all want to spend our time dooing meaningful things so we ... bla bla ...
have to make an app for that".

Come on, I think this is just bullshit. Yes, the premise is correct, people
are working too much on stuff they don't like (and we have to fix that), but
solving this problem via some time-managment-assistant-whatever-app (oh, there
are surely some contrived ML problems to solve here) is just hilarious.

