
Why We Use OCaml - antouank
http://tech.esper.com/2014/07/15/why-we-use-ocaml/
======
iamsohungry
I think you missed one of the most compelling things about OCaml: it's very
arguably most performant system in existence which also provides the user with
a strong type system. C/C++ provide performance but not a strong type system,
which results in huge numbers of bugs. Other languages provide strong type
systems, but in exchange give up a lot of performance. OCaml is somewhat
unique in this combination of features.

I say "somewhat unique" because there are other languages in this space: Rust
in particular may be the language of choice for these feature needs in the
future.

~~~
andrioni
I thought F# and Haskell were at least on the same level of performance, if
not faster. Is it not the case?

~~~
jlouis
These questions often depend on how much time you are willing to spend making
things fast. OCaml has an extremely predictable performance curve, which is
nice when you are writing code that has to run fast. In turn, productivity is
good because you don't get into situations where you have to rewrite code to
make it faster in many cases. Even for brute-force algorithms, it tend to run
fast enough that it would work well.

Over F#, OCaml provides a module system. This helps programming in the very
large.

Over Haskell, OCaml provides a module system, and strict evaluation. The
latter is a contended point, but proponents of OCaml claim it leads to
memory/execution predictability. In Haskell (GHC) you often have to turn on
optimizations in order to understand how your code will perform in reality,
whereas byte-code interpreted OCaml acts just like natively compiled OCaml
space wise, but is roughly 10 times faster in execution speed.

~~~
ics
Hey but GHC just got -XStrict!
[https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746...](https://github.com/ghc/ghc/commit/46a03fbec6a02761db079d1746532565f34c340f)

~~~
TuringTest
But will idiomatic Haskell work with that option turned on? Genuine question.

Wouldn't it change the require programming style to make use of the strict
setting?

~~~
ics
Currently you can deal with strictness using Bang Patterns. The addition of
Strict and StrictData with -XStrict simply lets module writers cut down on
that noise and communicates intent. It isn't meant to change or split _the
language Haskell_ in two; except for testing, you probably wouldn't go
enabling it everywhere just 'cause.

More info on strictness and Bang Patterns:
[https://wiki.haskell.org/Performance/Strictness#Explicit_str...](https://wiki.haskell.org/Performance/Strictness#Explicit_strictness)

This was posted to r/haskell today and helps explain things a bit:
[http://blog.johantibell.com/2015/11/the-design-of-strict-
has...](http://blog.johantibell.com/2015/11/the-design-of-strict-haskell-
pragma.html)

------
lobster_johnson
I always thought OCaml looks like a language which should be fantastic for
Erlang-style actor programming or Go-style network programming.

Every few years I take another look. Last time I researched this, I came
across a bunch of incipient attempts at distributed, concurrent programming
frameworks, but they were all abandoned around 2009. I couldn't find any
mature, maintained frameworks, any easy-to-use concurrency primitives (lwt
has, to my untrained eyes, a terrible API and is no match for goroutines or
Erlang processes), and apparently the global interpreter lock is still there.

~~~
corysama
You might be interested in
[http://www.ponylang.org/](http://www.ponylang.org/)

~~~
lobster_johnson
Pony looks nice, but unless it's something revolutionary I just don't have the
energy or patience to be part of the first wave of anything new.

That's why I'm not, at this moment, using Rust or Nim in production. I want a
mature toolset, a large, cohesive standard library, a large, active ecosystem,
etc.

Go only recently reached this stage. Node.js has been there for some time.
Elixir is there thanks to leveraging Erlang.

------
rtl49
In other words, they like the fact that it has features typical among
languages oriented toward functional programming.

There's no cost-benefit analysis here discussing the obvious pitfalls from a
business perspective, such as a much reduced talent pool and probably higher
salaries for the few programmers who are comfortable working with such an
uncommon language. There's also no discussion about why they believe a
business offering a calendar application needs to use such a technically
demanding language. This would be more understandable for, say, Jane Street
(high-frequency trading), but for this particular business my naive belief is
that this probably will not be the "competitive advantage" they claim it is.

~~~
fulafel
What are your reasons to believe the job market for hippy functional languages
is charcteristically highly paid and a "seller's market"? Judging from some
anecdotes and the proportion of FP programmers working in academia I would
have thought the opposite. Unless you're looking for the shallow end of the
talent pool...

~~~
rtl49
My prejudice is that anyone competent in functional programming is also
comfortable with other programing paradigms, in particular OOP. Not so much
the reverse. Thus the limited talent pool and higher wages.

~~~
LeonidasXIV
> My prejudice is that anyone competent in functional programming is also
> comfortable with other programing paradigms, in particular OOP.

That might be true, but if they are competent in both, that's often because
they have switched from OOP to FP and prefer the latter nowadays so if there
is a selection between otherwise equivalent jobs, they would tend toward the
FP job.

~~~
rtl49
Perhaps, as you suggest, attracting more talent is one benefit of using an FP-
oriented language for their codebase. It would have been nice to see this
claim evaluated in the context of a cost-benefit analysis including the costs.
This article, which claims that OCaml provides a "competitive advantage,"
doesn't provide that. Thus I don't believe it is a useful source of
information for evaluating the merits of OCaml in particular, or FP in
general, in a production environment.

------
sytelus
Another naive arguments for why language X is better. Native and 3rd party
libraries+frameworks far outweigh usability and productivity gains than few
cool language features. Most features mentioned in article are available in
mainstream languages at certain extent that is acceptable for professional
development at scale. This is not to make case against OCaml - it is nicely
designed language indeed - but the case should be made from beauty and "as
matter of taste" perspective rather than productivity and business
justification perspective.

~~~
rwmj
Pattern matching, strong typing with type inference and mutability by default
are certainly not available in "acceptable" mainstream languages. Also OCaml
is highly productive, very fast to run, and you can just call down to C when
you need to use a library.

~~~
sytelus
Productivity gains by well tested vast number of libraries and frameworks far
far outweigh gains due to language features such as pattern matching. Sure you
can drop down to C from pretty much any language but most setups attempt to
minimize that because maintaining hybrid language infrastructure (build/unit
tests/upgrades/logging/auth etc) is typically expensive over long run. Also,
may be calling libraries may be ok but using entire frameworks is much harder
to use cross language.

~~~
ldrndll
> Productivity gains by well tested vast number of libraries and frameworks
> far far outweigh gains due to language features

I see this argument all the time. I don't know if the type of software
development I do is special (I doubt it, it's fairly standard business
software), but the amount of time I spent on business logic dominates total
development time.

Past a certain fairly low threshold of core libraries (HTTP, JSON, CSV,
database bindings, standard stuff like that), the amount of time libraries can
save you is dwarfed by the cost of refactoring all that business logic.

On the other hand, if the language is so niche as to lack the basics, you can
find your entire development budget spent on building functionality other
languages offer out the box. I don't think OCaml is that niche...

------
e_d_g_a_r
Extra note, now can install OCaml with npm, just

$ npm install install_ocaml -g

$ install_ocaml

~~~
bsg75
Genuinely curious, why would someone want to use a Node package manager to
install OCaml, instead of the more "traditional" approach - yum, apt, ... ?

[https://ocaml.org/docs/install.html](https://ocaml.org/docs/install.html)

~~~
nv-vn
Better yet, why not bootstrap with OPAM?

------
mackwic
I don't know if it brings anything new on the table. Also, I am not convinced
that Ocaml is state-of-the-art in term of development productivity, relase-
management, debugging, etc. Anything any non-trivial project could want.
Language features is not the only thing we need.

Yes, the OCaml tooling has really improved recently, and the OCaml workflow
has been more and more smoother. Still. I wont recommend it for a business.

So, if the original author read this, could you answer these questions about
_how_ do you ship products with Ocaml:

\- How do you do Quality Assurance ? (anything from unit-testing, integration
testing, functional testing, etc. I guess you have to do it a lot to check
that Gmail didn't break its integration). Testing in isolation has its share
of challenges in Ocaml.

\- How do you manage your builds and releases ? Private Opam repositories ?
Directly shipped to Google ? Do you have beta/staging channels ?

\- And last but not least, what have been the pain points so far and have you
been able to fix them or do you just work with it ? (it happens with any tech
stack, but it's good to know what the trade-off are)

I am very curious how this could work at "entreprise-scale" and I would be
glad to have some real world examples of ocaml in production.

~~~
tegeek
If you've a look at F#, you get all of the things you said plus OCamel syntax
(without functors etc.).

~~~
kyllo
What do you mean by "without functors?" F# doesn't have a way to define a
`map` function that is generalizable to arbitrary data types?

~~~
pdpi
OCaml functors are not the same thing as Haskell functors — in OCaml they
refer to mappings from modules to modules.

[https://realworldocaml.org/v1/en/html/functors.html](https://realworldocaml.org/v1/en/html/functors.html)

~~~
ufo
"Functor" might just be the most overloaded term in computer programming...
Just of the top of my head it has totally different meanings in Ocaml, Haskell
and C++.

~~~
kyllo
They're not totally different between OCaml and Haskell. They're based on the
same concept from Category Theory: a mapping of objects and morphisms from one
category to another. It's just that Haskell functors are at the type level and
OCaml's functors are at the module level.

Apparently F# has support for neither style of functor--it doesn't have
parametric modules and it also doesn't have typeclasses. So in F# `map` is
defined independently for each type:

    
    
       Set.map : ('a -> 'b) -> 'a Set -> 'b Set 
       Seq.map : ('a -> 'b) -> 'a seq -> 'b seq 
       List.map : ('a -> 'b) -> 'a list -> 'b list 
       Array.map : ('a -> 'b) -> 'a [] -> 'b []

------
thalesmello
OCaml is a nice language and it surely has advantages. But don't treat that as
a competitive advantage. All of the benefits mentioned can be easily found in
other programming languages, except for maybe pattern matching, but that can
be easily replaced with similar constructs.

Using a not very popular programming language can actually make it harder for
you to hire people.

~~~
junke
> Using a not very popular programming language can actually make it harder
> for you to hire people.

This is a very popular opinion, but I never see anyone taking the time to
bring actual arguments. Do you have any experience hiring people or are you
just spreading this seemingly self-evident claim?

If a language is popular, wouldn't more companies want to hire for it, which
would make recruiting harder? See
[http://blog.activelylazy.co.uk/2013/05/27/choosing-a-
program...](http://blog.activelylazy.co.uk/2013/05/27/choosing-a-programming-
language-recruitment/). Also, being popular means that it is being known by a
wider audience of people: isn't it harder to filter through all the applicants
who say they can write in the popular language?

~~~
mordocai
As someone currently hiring for a mid level popularity language (ruby) I find
that we don't have as many applicants as we'd like and that many people who
apply have ruby on their resume but have never done an actual project in it.

We also do javascript and, despite its popularity, we also get quite a few
applicants who have it on their resume and have never used the language for
anything useful.

Personally, my opinion is just hiring is hard. It is a very valid point though
that if you are not willing to hire remote (which my company is not) you are
very limited when trying to hire for less popular languages. Alternatively
just train people, but that can be expensive.

~~~
rlander
_" The only thing worse than training employees and losing them is to not
train them and keep them."_ Zig Ziglar

------
hacker_9
I'm not a user of OCaml, but here is a counter-argument for C#:

 _First-class functions_

C# has closures, and can pass function pointers with delegates.

\--

 _immutability is the default_

 _Mutability can be a useful tool in some situations, but it is often
unnecessary and potentially harmful._

I think this point has probably been argued to death by now, but I still can't
see this as a good idea. 'Side effects' are really just a reality of software
development. For example if I want to fade in a GUI element on a page, I don't
want to create a new element for every transition change. Theres nothing wrong
with mutable state, but it is nice to have immutability for _some_ use cases.
In this case c# has valuetypes, and the const/readonly modifiers.

\--

 _Strong static type checking_

Yep C# has had this since the beginning. And you can even use 'dynamic' if you
really want which moves all type checking to runtime.

\--

 _Algebraic data types and pattern-matching_

I feel like these are more buzz words than actual substance. The Html example
given also doesn't seem exactly clear to me how the operations are being
performed. Here's a pseudo c# way of doing it:

    
    
        rootHtmlElement
            .SelfAndDescendants()
            .OfType<DivElement>()
            .Where(d => d.Attrs["class"] == "foo" || d.Attrs["class"] == "bar")
            .Select(d => d.ChildElements.OfType<TextElement>().FirstOfDefault())
    

_the typical object-oriented implementation of this in Java would involve
multiple subclasses of a common base class._

I assume they mean that all element types would inherit from a base
IHtmlElement? This seems like a good thing to me.

\--

 _Type inference_

Again C# has these abilities with 'var a = 0' for example. It won't infer
method return types, not because it couldn't, but because it's just generally
clearer to have the explicit return type written there in the code for the
reader.

\--

 _a replay-capable debugger_

C# has intelliTrace for this. Though I expect both suffer from the same
problems, slow execution while in use, and huge memory footprint.

~~~
mbrock
> _I feel like these are more buzz words than actual substance._

Um, both those concepts (algebraic data types and pattern matching) are very
clearly defined, classic language features. Why would they be substanceless
buzz words?

~~~
hacker_9
When I think of 'pattern matching' I think of some complex idea like brain-
level parsing of text to an AST via matching of syntax patterns. But what
OCaml pattern-matching really is is just the equivalent of a C# switch
statement, or if/else-if statements.

~~~
mbrock
You might think of that but that's not what it means in this context. ML-style
pattern matching is a concise way to match nested structures and
simultaneously bind variables to arbitrary subelements, which is particularly
useful when combined with algebraic data types. Both are classic features of
ML and derived languages since the early 70s. They're not buzzwords just
because you don't know what they mean.

