
Real World OCaml - anandabits
https://realworldocaml.org
======
srean
For the early adopters and experimenters amongst you, you might like Felix
[http://felix-lang.org/share/src/web/tutorial.fdoc](http://felix-
lang.org/share/src/web/tutorial.fdoc)

It is a whole program optimized, strongly typed, polymorphic, ML like language
that can interact effortlessly with C and C++ code and has coroutines baked
in. Its own demo webserver is based on coroutines. It uses a mix of lazy and
eager evaluation for performance and compiles down to C++. Execution speed is
comparable to C++, mostly better. Its grammar is programmable in the sense
that it is loaded as a library.

With inaccuracies in analogies assumed, Felix is to C++ what F# is to C# or to
some extent Scala is to Java.

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/tools.fdoc](http://felix-
lang.org/share/src/web/tools.fdoc)

The author likes to call it a _scripting_ language but it really is a
fullfledged 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 quite
fast and not hard to beat or meet C with.

~~~
Rickasaurus
Hrm, what do you think about rust vs Felix? They seem to be targeting the same
problem.

~~~
skaller
Rust and Felix both try to be general languages so they're both targeting
that. Felix has a better type system. Rust provides more secure but restricted
protocol for concurrency, Felix has no such restrictions, it's specifically
designed to support shared memory concurrency, which Rust specifically doesn't
allow. Rust uses message passing but organises via the memory management
mechanism to do it very fast.

~~~
dbaupp
Note that Rust does allowed shared memory, either via "unsafe" code (i.e. same
flexibility & dangers as in C, but the compiler only accepts it when wrapped
in an `unsafe {}` block, so it's clear that you need to be careful), or higher
level wrappers around this like Arc[1] for immutable shared memory, or
RWArc[2] & MutexArc[3] for mutable shared memory.

 _> Felix has a better type system_

What do you mean by this? From what I can see, the only way Felix encodes any
form of memory safety (e.g. dangling pointers) in the type system is by
garbage collection.

[1]: [http://static.rust-
lang.org/doc/master/extra/arc/struct.Arc....](http://static.rust-
lang.org/doc/master/extra/arc/struct.Arc.html)

[2]: [http://static.rust-
lang.org/doc/master/extra/arc/struct.RWAr...](http://static.rust-
lang.org/doc/master/extra/arc/struct.RWArc.html)

[3]: [http://static.rust-
lang.org/doc/master/extra/arc/struct.Mute...](http://static.rust-
lang.org/doc/master/extra/arc/struct.MutexArc.html)

------
brokenparser
Debian describes OCaml as follows:

Objective Caml (OCaml) is an implementation of the ML language, based on the
Caml Light dialect extended with a complete class-based object system and a
powerful module system in the style of Standard ML.

OCaml comprises two compilers. One generates bytecode which is then
interpreted by a C program. This compiler runs quickly, generates compact code
with moderate memory requirements, and is portable to essentially any 32 or 64
bit Unix platform. Performance of generated programs is quite good for a
bytecoded implementation: almost twice as fast as Caml Light 0.7. This
compiler can be used either as a standalone, batch-oriented compiler that
produces standalone programs, or as an interactive, toplevel-based system.

The other compiler generates high-performance native code for a number of
processors. Compilation takes longer and generates bigger code, but the
generated programs deliver excellent performance, while retaining the moderate
memory requirements of the bytecode compiler. It is not available on all
arches though.

~~~
rwmj
_It is not available on all arches though._

Although in practices the arches that lack a native OCaml compiler don't
matter.

In RHEL we ship OCaml natively for everything _except_ S/390 and AArch64.
AArch64 will be important, but since hardware doesn't exist in a form you can
buy for servers, we're happy to wait for upstream to implement this. We'll
probably help them out with hardware too.

Edit: We maintain our own PPC64 backend.

~~~
apaprocki
We actively use/used OCaml in production on SPARC/Solaris, POWER/AIX, HP-
UX/IA64. (The optimized compiler wouldn't build on AIX.)

~~~
rwmj
Various backends for less used architectures are maintained out of tree, eg
here:

[https://github.com/retired-camels/ocaml](https://github.com/retired-
camels/ocaml)

------
ori_b
Ocaml: Love the language, but I don't think I've seen a worse standard
library. I don't mean that it's sparse -- I don't mind that so much. I mean
that it's really just badly designed. For example, global, mutable variables
in a functional language? Really?

Thankfully, Jane Street and the Batteries Included projects are supplementing
it, but I'm still of the opinion that the standard library should be torn out
and replaced with something nice.

~~~
avsm
It's important to remember that the standard library is the _compiler standard
library_. It's actually very useful to have it be so minimal when compiling
OCaml to odd embedded and microkernel targets (such as our own MirageOS at
[https://openmirage.org](https://openmirage.org)).

We took an explicit decision not to use the compiler standard library in Real
World OCaml, and instead work using the Core stdlib from Jane Street. I think
it's quite a testament to the modular power of OCaml that they managed to not
only separate the standard library from millions of lines of internal code,
but also to make it so usable for external users in a brief 12 months.

There are a lot more developments coming soon, of course: see my groups
research page at [http://ocaml.io](http://ocaml.io) for some of the projects.
I've been lapse at updating it in the past few months, but normal service
shall resume very shortly...

~~~
edwintorok
Even if you don't use / plan to use the Core stdlib, the book is quite useful.

------
cju
Here is a description of OCaml usage at Jane Street :
[https://queue.acm.org/detail.cfm?id=2038036](https://queue.acm.org/detail.cfm?id=2038036)

ocaml.org have a list of users:
[http://ocaml.org/companies.html](http://ocaml.org/companies.html)

Some "big" companies in the list: Facebook, Citrix, Dassault Système.

~~~
avsm
Another cool one from CUFP this year is how Facebook is using OCaml to add
incremental type inference to their vast PHP code base. There's (slightly hard
to see video) here, but I'm sure Facebook will publicize it more widely when
they're ready.

[http://www.youtube.com/watch?v=gKWNjFagR9k](http://www.youtube.com/watch?v=gKWNjFagR9k)

------
avsm
For anyone curious to hear more and is at QCon SF today, I'll be speaking
about a new library operating system we've been building in OCaml for the past
few years. The slot is in a couple of hours at 1030 PST.

qcon link: [http://qconsf.com/presentation/my-other-internet-
mirage](http://qconsf.com/presentation/my-other-internet-mirage) my slides:
[http://decks.openmirage.org/qcon13/](http://decks.openmirage.org/qcon13/)

------
bsg75
Where is OCaml's place in the current world?

I find it interesting as it seems to generate little "buzz", but has two new
books this year, and is a pre-cursor to another functional language that
itself seems to be gaining traction, and is yet produced my Microsoft: F#

My observational / untested impression is OCaml seems to be more practical,
and maybe a little easier to transition to for someone like me who uses mostly
Python and Go, and a lot of bash/awk/sed/grep.

~~~
eschulte
A major limiting factor is that OCaml has _no_ support for parallelism, and
due to it's use of a global interpreter lock for GC it can't run multiple
threads.

That said it's great to program in (like Haskell with convenient IO and
semicolons) and it compiles to blazing fast executables.

~~~
rwmj
This is by choice, because single thread performance matters more, and you can
use fork or MPI to scale across NUMA nodes and clusters much more scalably and
safely.

~~~
eschulte
Having used fork/join to parallelize an OCaml genetic algorithm, I can say
from experience it is neither safe nor practical.

Edit: Intentionally only supporting single-threaded processes is a perfectly
fine design decision, however I haven't seen this argument made for OCaml,
rather I've seen "multi-threading our GC would be hard" as the justification
for the single-thread limitation. Admittedly it was 3-4 years ago when I last
had to deal with this.

~~~
avsm
There are now several experimental multithreaded OCaml runtimes floating
around, which also have the key property of not slowing down the single-
threaded case. I don't expect multicore to remain a limitation for OCaml in
2014.

~~~
chc
My impression was that the core team was actively opposed to adding
parallelism support. Has this changed?

------
pjmlp
Also interesting read,

"Unix system programming in OCaml",
[http://ocamlunix.forge.ocamlcore.org/](http://ocamlunix.forge.ocamlcore.org/)

~~~
edwintorok
Although not a book per-se, the tutorials on the OCaml.org site are based on
the old ocaml-tutorial.org ones, which is among the ones I used to get started
(there was no Real World OCaml, or OCaml from the Very Beginning at the time):
[http://ocaml.org/tutorials/](http://ocaml.org/tutorials/)

For future reference, all books should be listed here:
[http://ocaml.org/books.html](http://ocaml.org/books.html)

------
ralphc
In my progression of Haskell-OCaml-Common Lisp-Clojure-Scala, I remember OCaml
having odd edge cases, modules of functors or some such that didn't really
help me in solving real world problems (this was 2007-2008 so my memory could
be off). I'm currently a fan of Scala, which has all the functional and
Algebraic Data Type goodness I remember from OCaml but is more "practical",
more companies and projects are using it, plus I work in the JVM ecosystem.
Any reason to go to OCaml now instead of Scala?

~~~
elehack
It depends on what you are working on. OCaml lets you interact more closely
with Unix and with C libraries, if you need that. It also has a lot faster
startup time and lower memory overhead, making it somewhat more suitable for
writing Unix-style programs that need to run quickly with low overhead.

I also moved from OCaml to Scala for my primary programming, and have really
enjoyed it. The functional goodness on top of JVM is a major win for the kinds
of things that I primarily work on these days.

When I was working with OCaml, the community was going through a lot of work
on figuring out what the ecosystem should look like. This involved at least
two competing standard library extensions or replacements (Batteries and Jane
St. Core), growing pains in packaging & deployment, etc. The language was (and
still is) nice, but I could not, at the time, invest the time into dealing
with the ecosystem. Things seem to have improved a lot since then,
particularly with things like OPAN emerging, but Scala is still a better fit
for the work I do, and Haskell has been serving me well for command-line kinds
of things. But OCaml is a fine, practical language for a lot of things.

~~~
jimbokun
Is OCaml, then, a good fit for the kinds of programs many people have started
writing in Go?

Native, stand alone binaries. High performance (not sure how the Go vs. OCaml
benchmarks look right now). Good networking. More productive and less error
prone than C or C++. Less verbose than Java.

Haven't written any OCaml programs, but seems to check the same boxes. Go
seems to have a much better concurrency story with channels.

OCaml seems to have a much better type system and functional programming
support.

~~~
dllthomas
My understanding is that Go has a focus on concurrency which OCaml presently
lacks, and so it probably has an edge there (possibly a big one). Otherwise,
yes, OCaml is a good fit for the kinds of problems I understand Go to be used
for.

~~~
edwintorok
If you only need concurrency for I/O, and in particular networking then OCaml
is pretty good here:

\- you can use system threads. Yes you'll only be able to run one OCaml thread
at once, but when one OCaml thread gets blocked on I/O it switches to another.

\- you can do co-operative threading if you write your code in a monadic style
(there are a few libraries providing this: Lwt, Async, and in some sense
Equeue). Then you don't need to worry about the thread/context-switching
overhead, and the event-driven architecture should allow you to scale to
thousands of concurrent events. While this may sound scary at first, the
syntax is quite easy to understand, and it really is a lot easier than trying
to write non-blocking code in C with lots of callbacks.

In particular have a look at Ocsigen, and Eliom that provide a web-server and
framework: [http://ocsigen.org/tutorial/](http://ocsigen.org/tutorial/)

Regarding the book have a look at the 'Concurrent Programming with Async'
chapter that shows how you can write a TCP server/client that doesn't block.

~~~
dllthomas
Good points.

------
weavie
This is a really good presentation on OCaml by one of the authors of this
book.

[http://youtu.be/hKcOkWzj0_s](http://youtu.be/hKcOkWzj0_s)

~~~
edwintorok
I find the recent ocaml meeting presentations quite useful and interesting
too, in the sense that it presents what people are using OCaml for, and what
tools people are working on:
[http://ocaml.org/meetings/ocaml/2013/program.html](http://ocaml.org/meetings/ocaml/2013/program.html)
[http://oud.ocaml.org/2012/](http://oud.ocaml.org/2012/)

------
jzelinskie
Crazy coincidence; I just met someone who works at Jane Street on Saturday. My
jaw pretty much dropped when he told me what his company does. When I got home
and did some research, I was blown away by their dedication. I'm very happy to
see a company realize the value in their language ecosystem and contribute as
much back as they have.

------
cgag
People asking about Golang may be interested in this article, where someone
considering rewriting a large python project choose a new language, where both
Golang and OCaml are among the candidates.

[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/)

------
LukeHoersten
In case anyone's interested, there's also a Real World Haskell book freely
available to read online:
[http://book.realworldhaskell.org/read/](http://book.realworldhaskell.org/read/)

I'd be interested to see how they compare.

