
Why OCaml, Why Now? - croyd
http://spyder.wordpress.com/2014/03/16/why-ocaml-why-now/
======
mas644
Look, I love OCaml and it's my favorite language syntax-wise, but the real big
elephant in the room is not its JS-backend maturity. Rather it doesn't have
kernel thread support...all threads are user-level just like Python due to a
global lock for garbage collection. This means threads do not run concurrently
across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since
processors went multi-core. Intel is talking about having hundreds of cores on
a single die by next decade and having programs that can't take advantage of
that is extremely limiting.

Xavier Leroy (the creator of OCaml) and his team at INRIA didn't think this
was a big deal because when they were writing this stuff, processors were
single core and had been since the beginning. Sure there were multiprocessor
machines (not the same as multicore as there are multiple die), but those were
only meant for servers/workstations. OCaml seemed very promising around 2006,
the peak and end of the single core era with the Intel Pentium 4. What made
OCaml so impressive was not only was it this beautifully simple, high-level
functional language, but that the native compiler produced very fast code that
was comparable to C/C++ performance. However, as multicore processors were
introduced (Intel Core, Core 2), not having this capability made writing new
code in OCaml less appealing. There are solutions like MPI, but that's lame.
The same excuses you hear in the Python world about having true multithreading
you hear in the OCaml world. Microsoft was able to do it with F#, which is
essentially a clone of Caml by targeting their .NET CLR. Haskell is able to do
it with GHC.

I still think OCaml is a wonderful language -- not having true multithreading
doesn't make it useless. However, to me it has become more like a statically-
typed Python which I can use for scripting. Having to use hacks like MPI to do
multicore processing is a huge turn off in a multicore world. This is again
nothing against the language, but the standard implementation needs a
concurrent garbage collector and kernel threads. Otherwise I think OCaml may
be doomed to irrelevance in the long run, which would be truly sad.

~~~
edwintorok
Apparently multicore ocaml is worked on again:
[https://github.com/ocamllabs/compiler-
hacking/wiki/Multicore...](https://github.com/ocamllabs/compiler-
hacking/wiki/Multicore-runtime) [https://github.com/ocamllabs/compiler-
hacking/wiki/Multicore...](https://github.com/ocamllabs/compiler-
hacking/wiki/Multicore-OCaml)

That being said you can still use multiple cores by using multiple processes,
and that doesn't necesarelly imply MPI. OCamlNet (and probably some other
libraries) provide a way to communicate between multiple OCaml processes.

~~~
mas644
Good to see work is being done on it, but until it's in the main
implementation for at least a year...I wouldn't trust it on anything that
matters.

The advantage of kernel threads is that they have way less overhead than a
process (both in context size as well as more efficient memory caching at
processor and OS level)...though more than a user-level thread. If there isn't
any sort of message passing between two processes, the only mechanism I can
think of of sharing data is shared memory (i.e and mmap) which is just as
efficient as threads sharing the same process heap...but awkward (yes there
are sockets, file IO, signals, queues, etc, but not as efficient). Even if
OCaml provides a way to abstract that to be more palatable + safe -- my
argument is that in a multicore world, kernel threads must be a first class
citizen and the programmer shouldn't have to resort to tricks to harness it --
otherwise it's a major flaw that is going to prevent future adaptation. Also,
as the number of cores increase, this is going to matter more and more...so
hopefully this stuff gets out in the wild soon.

------
chimeracoder
I'm glad that the author is picking up a new functional programming language,
but choosing OCaml over Haskell because of support for the Javascript
implementations strikes me as choosing a BMW over a Mercedes[0] because of the
number of cupholders it has.

If you don't have a particular goal in mind (ie, "I work at Jane Street and
need to be compatible with our existing code"), there are a number of other
factors in the OCaml vs. Haskell discussion that are far more important.

> JS is the only realistic way to write web apps

Javascript is the only realistic way to write _the front-end_ of webapps. But
that doesn't mean you're wedded to it for your backend technology. And I don't
think _either_ OCaml or Haskell have sufficiently advanced DOM bindings, etc.
that I'd recommend using either one for client-side work in the browser.

[0] I'm not sure if this is a flamewar topic for car nerds - my point is to
pick two high-end luxury cars that are both well-respected and each have their
own merits.

~~~
skybrian
It sounds like you have a very language-centric view of the world. In
practice, deployment is everything. (Why do people write code in Objective C?
Because iPhone.)

Having a solid implementation for your target platform is very good reason to
pick a language.

~~~
chimeracoder
> It sounds like you have a very language-centric view of the world.

> Having a solid implementation for your target platform is very good reason
> to pick a language.

I'm not sure where you got that out of my comment; it was exactly the
opposite.

My point was that _neither_ OCaml nor Haskell have particularly strong
implementations in this area (to my knowledge). Last time I checked, the
ability to write Javascript using both languages was of experimental and/or
novelty use only (hence the "cupholders").

And that still doesn't change the fact that a web app can be written in any
language - the only part that needs to run in Javascript is the client-side.
Depending on how you architect your app, this may not be much at all. (There
are very few webapps that actually _need_ much logic in Javascript - if you
want to avoid JS[0] while writing complex webapps, it's actually very easy to
do so in many cases.)

[0] or anything else that is translated into JS

~~~
coolsunglasses
Haste is a strong, useful, and impressively complete Haskell to JS compiler.

Fay is used in production apps as well.

PureScript is less mature still but pretty nice.

~~~
spyder81
I looked at Haskell options - fay and haste are both good, but not complete
(try compiling tagsoup). GHCJS works, but generates 5mb JavaScript files.

This is what I meant when I said "by virtue of support for existing
libraries". js_of_ocaml translates compiled bytecode and can therefore make
any pure OCaml library work in JavaScript without recompilation.

------
srean
Felix is to C++ what F# is to C# [http://felix-
lang.org/share/src/web/tut/tutorial.fdoc](http://felix-
lang.org/share/src/web/tut/tutorial.fdoc) (I am not the author, just excited
about this language) OCaML programmers will feel immediately at home.

It is a mature yet actively developed whole program optimized, strongly typed,
polymorphic, ML like language that can interact effortlessly with C and C++
and has coroutines and threads baked in, although use of threads is somewhat
discouraged. It has type-classes as well as modules. Functions written in it
may be exported as a CPython module. This might be useful if one wants to
gradually transition from a Python based src tree.

It uses a mix of lazy and eager evaluation for performance and compiles down
to C++. Execution speed is comparable to hand written C++, mostly better. Its
grammar is programmable in the sense that it is loaded as a library. So in the
same way that languages may acquire libraries, Felix may acquire domain
specific syntax.

It is also mostly a one man effort but with a feverish pace of development so
it comes with its associated advantages and disadvantages.

Tooling info is here [http://felix-
lang.org/share/src/web/ref/tools.fdoc](http://felix-
lang.org/share/src/web/ref/tools.fdoc)

The author likes to call it a scripting language but it really is a full-
fledged statically compiled language with a single push button build-and-
execute command. [http://felix-lang.org/](http://felix-lang.org/) The
"fastest" claim is a bit playful and tongue in cheek, but it is indeed
remarkably fast.

~~~
kenko
AFAICT you mention Felix whenever OCaml comes up, generally saying more or
less the exact same thing each time.

~~~
srean
Absolutely correct, and for F# too. I do want to get the word out, it really
needs some love and eyeballs, but perhaps I overdo it.

------
boothead
If ocaml is a language waiting for a killer app, this might be it:
[http://www.openmirage.org/](http://www.openmirage.org/)

There was a presentation at the FP eXchange in London last Friday about mirage
and many a mind was blown!

~~~
andolanra
Haskell also has the analogous HaLVM:
[https://github.com/GaloisInc/HaLVM](https://github.com/GaloisInc/HaLVM)

------
lholden
I've found it interesting that OCaml hasn't had more interest given the amount
of recent momentum in Haskell.

Haskell is an Ivory Tower. The features that generally draw one to the
language also tend to be the things that eventually push one away. Haskell has
grown a lot over the years however as the language evolves to allow general
programming within a pure framework.

OCaml on the other hand tends to make a compromise, acknowledging that the
programmer occasionally needs a different tool for the job. OCaml allows the
programmer to opt into things like mutability and objected oriented code when
the need arises. These compromises can also be seen as the languages downside
however.

I find it interesting that the driver for the author into OCaml is
JavsScript... but it's nice to see OCaml come up a bit more often. :)

~~~
tel
I feel it's similar to any competitive environment: differentiation requires
making strong tradeoffs. Haskell's choice of tradeoffs---while initially very
ivory tower---have led to to become a strongly differentiated language. You
not only learn how HM typing and full commitment FP feel, but also how to
structure code purely, compose effects, and abuse laziness.

So for the very same reasons you give---Haskell has made fewer tradeoffs for
"practical" programming---Haskell has become something valuable and
interesting. On those tides the community has grown.

~~~
jamii
Another big obstacle was that the INRIA license effectively prevents forking
the language (you can only distribute modified compilers as original source +
patch, not as eg a github repo) so for a long time there was a bottleneck on
the language evolution. Lots of useful extensions (eg delimited continuations,
staging) wilted and died because of that.

The rise of OcamlPro and Ocaml Labs does give me hope for the future of the
language. There is already renewed momentum behind fixing packaging and
handling multicore.

Now if someone would just figure out ad-hoc polymorphism (just pick one of the
dozens of propasals) and maybe even document camlp4/5....

------
lmm
For me Scala has been the not-quite-as-good-as-haskell-but-more-industrially-
acceptable language. I'd be very interested to see a more neutral comparison
of functional languages for compile-to-JS, because if anything Haskell seems
more popular for that - I hadn't heard anything about compiling OCaml to JS
before this.

~~~
oddthink
I just started at a Microsoft shop a few months ago (first time for
everything), and I actually quite like F#, now that I've had a little while to
play with it. It's a good contender for the NQAGAHBMIAL throne.

Having used CMUCL/SBCL for a while, I always found ocaml's "well, you can
compile your code, but then you can't run it in the REPL" to be off-putting.
(For my purposes the CLR JIT compiler for F# is good enough.)

~~~
NoodleIncident
Posted 20 minutes ago, and this post already shows up when you google
"NQAGAHBMIAL". Impressive...

~~~
andrewflnr
And now yours. And nothing else.

Is it "not quite as good as Haskell but maybe it's alright language"?

~~~
oddthink
From the parent, "not-quite-as-good-as-haskell-but-more-industrially-
acceptable language". Not intending to be obscure.

------
jlukecarlson
OCaml is actually taught in the second level computer science course at my
university. I think its a great language for learning topics like recursion
especially with its pattern matching. Its also a great intro to functional
programming

------
fnbr
This might be entirely superficial of me, but I always preferred Haskell over
OCaml simply because OCaml required me to type ";;" after every line.

The only real reason that I can see to choose OCaml over Haskell is that if
you learn OCaml, you might be able to work at Jane Street. Is there a strong
argument for abandoning my Haskell-ing for OCaml?

~~~
avsm
> This might be entirely superficial of me, but I always preferred Haskell
> over OCaml simply because OCaml required me to type ";;" after every line.

That's easily fixed: only the toplevel requires ;; (to commence evaluation of
the phrases you've typed in). Just don't use it in normal code and everything
will parse fine.

~~~
andrewflnr
> everything will parse fine.

That's an exaggeration. There are circumstances in files where it's necessary.
I didn't realize this, which hung me up for a long time.

~~~
jon_smark
Would you care to share an example? I've _never_ encountered a justifiable
need to write ;; outside the REPL. The only uses of ;; I've encountered "in
the wild" were hardly reasonable: essentially top-level code that was not
wrapped in a "let () = ..." statement.

~~~
andrewflnr
I don't recall seeing that recommendation before this thread. That may just be
my blindness in skimming things too quickly. In any case, I think it indicates
a wart in the language when you have to wrap everything in otherwise useless
let blocks just to get it to parse.

------
marktangotango
OCaml is Object Caml right? What about SML? I always loved SML, but it never
got any traction at all. The O in Ocaml always turned me off, they cluttered
up the syntax with all the object notation.

Does anyone have any insight into why OCaml rose to (relative) prominence and
not SML?

~~~
detrino
Ocaml was always the more pragmatic language and for a long time the
implementation was significantly faster than anything SML offered. MLton came
along very late in the game and offers excellent performance, but doesn't
support separate compilation.

Edit: A more lengthy comparison:
[http://adam.chlipala.net/mlcomp/](http://adam.chlipala.net/mlcomp/)

~~~
marktangotango
Thanks for the perspective!

------
bunderbunder
Considering how strongly opposed the author is to dynamic typing, I'm actually
kind of surprised they'd consider OCaml's type system to be acceptable.

Technically, yes, it's a statically typed system. But its use of structural
typing instead of nominative typing effectively means it takes half the
compiler assistance you can get out of static type checking and chucks it out
the window. Using structural typing means that a type is nothing more than the
sum of its parts; nominative typing makes it possible to add further
specificity to types by naming them. This is huge. A language that doesn't do
this is a language that can't be taught to understand the difference between
12 meters and 12 Newtons.

~~~
jamii
You may be confused by the fact that the type system will notice the
equivalence of two types _if_ the implementations of both are public eg

    
    
        module M = 
        struct
           type newtons = int
           let inc some_newtons = some_newtons + 1
        end :
        sig
           type newtons = int
           val inc : newtons -> newtons
        end
    
        M.inc 1 (* this works *)
    
        module M = 
        struct
           type newtons = int
           let inc some_newtons = some_newtons + 1
           let in_newtons x = x 
        end :
        sig 
           type newtons
           val inc : newtons -> newtons
           val in_newtons : int -> newtons
        end
    
        M.inc 1 (* type error *)
        M.inc (in_newtons 1) (* this works *)
    

The use of hidden types in OCaml gives far better control over encapsulation
and implementation hiding than any over language I've used.

------
CmonDev
"...Facebook created ... a statically typed PHP variant..." \- so happy to see
another major tech company understand the merits of static typing.

~~~
_halgari
that's because PHP is such a horrible language you need static typing to make
sense of the crap. </snark>

~~~
CmonDev
Agree, same true for JS - so many people trying to fix the mess...

------
bsaul
How do those "to js" code generator behave when used together with frameworks
like backbone or angular ?

I know things like typescript or dart have special versions of the framworks,
but i'm curious to know how the ocaml to js tools behave ( since i've searched
for a decent strongly typed server side technology for years, that would be an
argument for me to try that language).

~~~
skybrian
I don't know about OCaml, but generally speaking, there is a foreign function
calling interface. You'd typically use it for integrating with large
standalone codebases you don't want to rewrite (say, CodeMirror) but typically
not for frameworky things. If you're going to use the same UI framework
there's not much point in switching languages.

------
qzwxecrvtb
Here's the plan -- eliminate perl, python, ruby, php or java or any slow-
starting jvm-based language(the featureless landscape of clojure for example),
and use just bash, sed, awk, ocaml(to replace the fear of 'C'), and we can
also do f# on windows, so there would be crossover between the worlds and
peace throughout the land.

