
OCaml 4.02: Everything else - yminsky
https://blogs.janestreet.com/ocaml-4-02-everything-else/
======
amirmc
Since I haven't seen any discussion here (yet), I went and looked at the
reddit submission. Thought others might find it interesting.

[http://www.reddit.com/r/programming/comments/25vr5t/ocaml_40...](http://www.reddit.com/r/programming/comments/25vr5t/ocaml_402_everything_else/)

------
cheepin
At what point is the language going to get serious adoption? It's mature,
unbloated, elegant, and fun to write. The only thing I really think needs
improvement is its multicore stuff.

~~~
Totient
The problem is that pretty much the entire standard library isn't thread safe.
It would take some serious work to get OCaml ready, unless you stick to
message passing between distinct processes.

~~~
photex
This just makes me reconsider spending any time with it at this point.

~~~
edwintorok
On the other hand there are quite good event-driven / monadic concurrency
libraries:

[http://ocsigen.org/lwt/manual/](http://ocsigen.org/lwt/manual/)
[http://projects.camlcity.org/projects/dl/ocamlnet-3.7.4/doc/...](http://projects.camlcity.org/projects/dl/ocamlnet-3.7.4/doc/html-
main/Equeue_intro.html) [https://blogs.janestreet.com/announcing-
async/](https://blogs.janestreet.com/announcing-async/)

For example you can use them to write HTTP services/clients that scale to lots
of concurrent connections without blocking, and the code you write is not that
much different from the one you'd write in direct-style.

------
zerr
Slight off-topic: Judging from H1B stats [0], Jane Street pays quite below the
market rate (for NYC finance sector). Also, they haven't sponsored any H1B's
for the last 3-4 years. I wander if these stats are reliable... Or maybe, JS
puts more emphasis into bonuses (on top of the base salary), in order to not
to disclose salaries?

[0]: [http://www.myvisajobs.com/Visa-Sponsor/Jane-Street-
Capital/2...](http://www.myvisajobs.com/Visa-Sponsor/Jane-Street-
Capital/281915_Salary.htm)

~~~
hackerboos
Aren't Jane Street mainly based in London? Being a UK based company may
explain the 'below market rate' salaries.

~~~
amirmc
Jane Street has offices in London and Hong Kong but their HQ is in NYC.

You don't need an H1B if you can recruit to a local office and then do an
internal transfer (after some time). No idea if Jane Street does this but I
know other tech companies do.

~~~
elemeno
Not much need to make internal transfers - London and Hong Kong are two of
world's largest financial centres so there's plently of local work to do and
it's not exactly hard to collaborate with colleages in NYC from London when
there's a good 4/5 hours a day of overlap when both offices are active.

Looking at salaries is misleading anyway - companies like Jane Street do most
of their compensation as bonuses rather than salaries. Having worked in the
proprietry trading world, salaries are generally on the low side, but your
bonus can be anything from 50%-100% of your salary upwards. It differs a fair
bit depending on what you do - a traders' bonus will be more volatile and
pegged to their performance that year, a back office dev will propably have a
more stable bonus year to year, but not as large.

------
thinkpad20
I've been a Haskell user for about a year now, and am pretty comfortable with
the language. Ocaml has a lot of things that I like (the module system seems
great; strict evaluation is a win; mutability/loops/etc without having to jump
through hoops). But every time I look at the actual code, I'm really turned
off by a few things:

* _let_ s everywhere, even at top-level. Haskell doesn't do this, which is a lot nicer.

* _let rec_. Wut?

* Apparently to produce code to run at top-level main loop you just assign it to a _let _ = ..._ , which looks really hacky.

* Double semicolons.

* Type variables annotated with _' a_. In Haskell, lowercase type names are variables, uppercase are constants (or type classes, but those aren't mixed).

* Mix of semicolons and _end_.

Haskell seems syntactically more elegant, has type classes which are (at least
on the surface) more straightforward than modules, though I don't know which
is more useful at the end of the day. Haskell's _do_ syntax is very nice.

That said, in many ways OCaml _seems_ much more like "my kind of language".
But there are a number of turnoffs.

~~~
tomp
Hint: double semicolons are not necessary in files (just in the REPL). Also,
personally I dislike Haskell's lower/uppercase conventions, and find OCaml's
syntax marginally better in this respect (although I think best would be pre-
declared parameters, like in C/Java/Scala/Julia).

------
andrewstuart
I'd like to like ocaml but its not clear to me why I would choose it above
anything else to write an application. I have the sense vaguely it might be a
good thing. A little reading and examination of some example source hasn't
thrown much light.

What's it good for? Why should I use it? Why is it a better choice than
language X or Y?

~~~
jgg
It's really fast, has minimal boiler plate and supports functional programming
without any of the "orthodoxy" of Haskell. That is, you can write a recursive
function but also write a for loop.

Imagine something that can compete with C and C++, but doesn't require all of
the low-level reinvention and memory management. It's like a high-level
language for smart people that doesn't feel entirely impractical. It has some
things that people bitch about (like having to use +. to add two floats and +
to add two ints), which don't really bother me that much.

If it were more popular and had better libraries/platform support (unless
that's changed drastically in the past year or so), it would be a serious
contender for general development. Being completely honest, I think Jane
Street is probably the biggest organization pulling OCaml, and from a navel-
gazing standpoint you can either view that as good or bad.

Use it because you learned it and thought it didn't suck, I guess?

EDIT: changed some phrasing

~~~
amirmc
> _"... unless that's changed drastically in the past year or so ..."_

Actually _a lot_ has happened in the last year or so. If you're not aware of
it, you could start by looking over the end-of-year post from OCaml Labs [1].
I'm aware that it's difficult to keep a central overview of all the progress
but there is a lot of work being done, in many ways, to improve the ecosystem.

[1]
[http://www.cl.cam.ac.uk/projects/ocamllabs/news/#Dec%202013](http://www.cl.cam.ac.uk/projects/ocamllabs/news/#Dec%202013)

~~~
jgg
Whoa, that's cool. I had no idea people were still working on it at that
level. The last thing I saw was a version of OPAM that didn't seem to work
that well...I'll have to go look around.

------
jordwalke
A couple of people have asked why you might choose OCaml over other languages.
I've not done as much OCaml work as others on this thread (I work primarily on
ReactJS (Facebook/Instagram's) functional UI framework), but I can offer a
different perspective as someone who is outside of the OCaml community, but
asking the same questions. Here are some of my personal findings.

I'll narrow any comparison down to the ML family of languages. Java/C++/ and
many other languages are just now beginning their slow, but inevitable
evolution into _becoming_ a dialect of ML (which IMHO is a sort of admission
of the ML/functional family superiority).

Once you embrace the power of pattern matching, it's hard to use anything but
an ML family language (StandardML/Haskell/F#/OCaml). I would program in any
one of those languages over Java/C++/Objective-C/JS.

Practical reasons why you might choose OCaml:

\- OCaml's records aren't as elegant as SML's but OCaml has labeled arguments
with optional default values which can satisfy many of the reasons why you'd
use records as arguments in the first place (and may be even more powerful in
some cases).

\- Two modes of compilation (fast native executable XOR fast compilation). Who
doesn't like options.

\- All the benchmarks I can find show that OCaml is very fast (around as fast
as C++).

\- Excellent JS target and and apparent commitment to maintaining it (as
someone building a JS library, this is very important to me) (and as someone
who wants to build apps and be able to instantly share them with everyone in
the world.)

\- Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox"
([https://github.com/jordwalke/VimBox/](https://github.com/jordwalke/VimBox/))
has configured it to complete as you type - like in Visual Studio etc.)

\- On very rare occasion, you'll run into a problem that is inherently better
suited to OO (dynamic dispatch). I can usually find a way to solve it with
functors/modules, but it's nice to know that you have OO in your back pocket
in case you ever need it. It's also nice to know you probably won't have to.

\- Finally, a common package manager (OPAM) is becoming standard. I look
forward to seeing how OPAM helps make the new dev experience and the code-
sharing/development experience seamless.

\- The module system is very powerful (SML's). Haskell does not have this, and
strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles
(but with more sugar)).

\- There's usually ocamlyacc grammars for most languages. Most examples of
languages, type systems, parsers are already in OCaml (or ML). It's a nice
(but small) perk.

\- Predictability. OCaml is not lazy by default. Lazy computations could
become problematic for low-latency applications (such as UIs) if a lot of
computation becomes is deferred until the moment a final dependency has been
satisfied, but by that time you may be close to your screen refresh deadline
and it may lead to a dropped frame. It would have been better to have been
computing while waiting for a final dependency. I'm not sure if Haskell (a
lazy language) has had this problem. You can opt into laziness in OCaml if you
would like to.

\- Mutability. I feel strange saying this, as such a huge proponent of
immutability, but sometimes you just need to hack something in place, mutate
some state and come back to clean it up later. (You can still use monads in
OCaml).

\- Tagged Variants (no need to predeclare variants, just pattern match on them
and OCaml ensures that only properly matched values ever make their way into
that expression).

\- Industry use is growing. OCaml is used here at Facebook and many other
places as mentioned.

\- There are many abstractions to choose from (Records, Objects, Modules,
Functors, First Class Modules, GADTs, ...).

OCaml Cons: \- There are many abstractions to choose from (Records, Objects,
Modules, Functors, First Class Modules, GADTs, ...).

(Edited for formatting)

~~~
mercurial
> Java/C++/ and many other languages are just now beginning their slow, but
> inevitable evolution into becoming a dialect of ML (which IMHO is a sort of
> admission of the ML/functional family superiority).

You can't be serious. The fact that they are borrowing some features from
functional languages is in no way an indication that they're going to turn
into an ML dialect. They will remain imperative languages, with all that
entails (mutability, inheritance, etc) for the foreseeable future. Hell, even
Scala isn't an "ML dialect".

~~~
jordwalke
It's a bit of hyperbole, sure, but I think there's some truth in it. For many
of these, the progress is pretty slow - starting with simple type inference,
lambdas. OCaml has imperative/OO features but it is still an ML language. As
other languages adopt many of the ML features they will retain their roots of
course. But I'd like to think they'll accumulate all of the good parts of an
ML language (pattern matching, better inference). It's possible that my belief
that ML languages are far superior to popular languages could be influencing
my outlook. But even after many years of programming in terrible languages
like Java it's clear within a week of programming in OCaml/ML that so many
problems that require "architecting" in Java/ObjC/C++ are just trivial chains
of functions and pattern matching in OCaml. How could the FP paradigm (ML in
particular) not prevail? I can't imagine a world where it doesn't.

~~~
mercurial
But none of these languages will ever adopt Hindly-Milner type inference,
which is the staple of the ML family. I mean, you have fist class functions
and pattern matching in Erlang, and a library for pattern matching in Clojure,
but this doesn't make them members of the ML family. And I really don't see
Java and friends evolving much beyond that.

~~~
jordwalke
Honest question: Why would/could they not? There has been a ton of research
published on extending HM type inference to support structural subtyping, row
polymorphism, extensible records which very closely model many (but not all)
of the concepts in Object Oriented systems.

~~~
mercurial
That's actually a good question. I suppose that it would be possible in theory
to try and reconcile the two, but I don't see that happening. And I don't know
how much you can extend HM to support the full C++ featureset. I'd be
surprised if it was possible.

~~~
jordwalke
I haven't seen the entirety of C++'s feature set added to an HM system, but
even OCaml has an OO system that's fairly complete. Many new functional
languages are adopting Daan Leijen's extensible records approach which can
model OO fairly well.
[http://research.microsoft.com/pubs/65409/scopedlabels.pdf](http://research.microsoft.com/pubs/65409/scopedlabels.pdf)

All of these are extensions of ML that are shipped into production today, so
it looks like more than just a theory at this point.

