
Plans for OCaml 4.08 - girvo
https://blog.janestreet.com/plans-for-ocaml-408/
======
a0
It's really great seeing this contributions from JaneStreet. If you're
interested in learning more about recent progress in the OCaml's ecosystem, I
recommend watching this talk: [https://www.infoq.com/presentations/ocaml-
browser-iot](https://www.infoq.com/presentations/ocaml-browser-iot)

------
jdonaldson
OCaml is a great pick for folks wanting to broaden their understanding of prog
languages. It has its own set of sensibilities (Fp with some imperative
features thown in, rather than the other way around). It'll force you to get
really good with ADTs, which is a good thing.

~~~
krick
Is there something you'd recommend for a person who wants to learn OCaml?
Maybe some book that has great exercises, or just a toy-project example for
which OCaml would be a much more "natural" pick than other languages?

~~~
cpeterso
Facebook's Reason ML might be a more approachable introduction to OCaml
concepts. Reason adds a cleaner, more JavaScript-like syntax on top of the
OCaml compiler backend.

The Reason team's primary focus appears to be compiling Reason/OCaml to
JavaScript. It's a nice language, but I'm not sure why they want to pass
through a OCaml "middle end" before emitting JavaScript output. Why not just
write a direct Reason->JavaScript compiler similar to TypeScript?

[https://reasonml.github.io/](https://reasonml.github.io/)

~~~
thedufer
There is no "OCaml middle end". Reason is parsed into the same AST as OCaml,
and then passed through the rest of the OCaml compiler.

------
weavie
When did Jane Street take over development of OCaml? I knew they were heavy
users, but I thought it was INRIA that were the main developers. This post
implies that JS are running the show now...

~~~
yminsky
That's not the intended implication, and Jane Street has in no way taken over
the show. Our PRs are discussed vigorously, just like everyone else's, and
they're definitely not always accepted!

Indeed, one of the great things about the OCaml compiler development process
is that the core team is highly skeptical, and does a good job of rejecting
marginal changes.

~~~
weavie
Ah ok, I totally misinterpreted. Thanks for clarifying (and thanks for all
your great work with OCaml!)

------
totalperspectiv
When I tried to really get into ocaml a few months ago I loved it! Until I
actually tried to put together a project with it. Every tutorial and doc
seemed to be slightly out of date or not compatible with some package version.
Real World Ocaml, while excellent conceptually, is between versions and most
examples were broken.

I reeeaaalllly wanted to love Ocaml, but it just seemed like a collection of
half baked tools and limited library support. So I learned Julia instead.

I would love to see a little unification and life come into ocaml to get its
dev tooling up to par with other modern languages.

I gave up on it when I realized I had been spending more time debuging example
code and conflicting versions of 'stdlib' type packages than i had been
actually writing any Ocaml code.

~~~
_hardwaregeek
Language ergonomics is a really underrated feature. I remember having to link
system libraries to follow an OCaml tutorial, which was extremely painful. Or
running into issues installing Snap for Haskell where the package manager
would basically go ¯\\_(ツ)_/¯. While on the other hand Cargo has been a breeze
to set up and work. Makes all the difference when your users aren't willing to
dive into the source code to fix the issue or wait for a StackOverflow/GitHub
Issue response.

~~~
openplatypus
Opam combined with Oasis
([https://ocaml.org/learn/tutorials/setting_up_with_oasis.html](https://ocaml.org/learn/tutorials/setting_up_with_oasis.html))
does pretty good job IMO.

My personal issue with OCaml eco-system is that for quality tooling Emacs
feels like the only option.

~~~
analogtsar
I am using VSCode with vscode-reasonml extension and I thought it is pretty
good. Am I missing something by not going with Emacs?

~~~
openplatypus
In all fairness I tried it few months ago. Auto-complete was hit and miss and
sometimes got false negative errors. Glad to here it works now apparently! :D

------
ericb
It will be interesting to see how the $200 million+ Tezos warchest affects the
popularity and development of OCaml. That seems to be a fairly large amount in
relation to the size of the current OCaml ecosystem, and the whole purpose of
the fund is to grow the ecosystem of Tezos which by necessity includes the
OCaml ecosystem.

~~~
woolvalley
For a smart contract platform, it's probably ok that ocaml isn't
multithreading friendly. But what a disappointment if this is still the case:
[https://ib-krajewski.blogspot.com/2015/11/ocaml-and-multithr...](https://ib-
krajewski.blogspot.com/2015/11/ocaml-and-multithreading.html)

At this point, if a language doesn't have first class support for
multithreading and static typing, I wouldn't start a new project in it.
Nullability support is pretty high up there too, but that is a far more
tractable problem.

~~~
gmfawcett
Modern OCaml multithreading is still a couple years away, the current (very
promising) approach is still at the design/experimental stage.

Out of curiosity, what is it about smart contracts that makes multithreading
so important? Why isn't multiprocessing enough? [edit: sorry, I mis-read your
comment. You said that multithreading probably isn't a big deal for this
problem.]

~~~
HumanDrivenDev
_Modern OCaml multithreading is still a couple years away_

It's been a couple of years away for the last 10 years.

~~~
gmfawcett
I know, and I hate sharing "it's coming soon" stories for that reason. But the
recent multicore progress-update does seem well conceived, and so personally
I'm giving them the benefit of the doubt. :)

~~~
laylomo2
For the record, the current story is that they are merging some multicore
things into 4.08, and it will only be available as an "experimental" feature.
So even after it is in the compiler, it will be a couple more revisions before
it is fully accepted.

~~~
gmfawcett
Right, I linked to these summary notes in a different comment:

[https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-
june...](https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-
june-2018-development-meeting-in-paris/2202?u=gasche)

------
WallWextra
This is a nice counterexample to the wisdom that production compilers all use
hand-written parsers. Of course, the current parser does suck, but...

~~~
swah
IIRC OCaml compilation was super fast and the errors were useful and pointed
to the correct line.

What is/was the problem with the current parser?

~~~
WallWextra
As the blog post says: "Error: Syntax Error".

Helpful error messages have not been my experience.

~~~
a0
Syntax errors are suboptimal. They are usually reported at correct location
and it's relatively easy to spot them.

On the other hand type error messages are simply awesome.

------
losvedir
How's the performance of OCaml, and what's its concurrency story?

I feel like on paper, at least, OCaml ticks all the boxes on my programming
language wishlist: non-nullability, ADTs, type inference, compiles to binary.
A lot like rust but a little higher level. But I've never really had a go at
it. I'm sort of reluctant to sink time in it if there's not a future, but it
seems to be kind of chugging along, not really gaining or losing ground,
AFAICT.

~~~
klibertp
The concurrency story is similar to what you get in Python. On one hand, you
have event loop implementations with various conveniences for scheduling
callbacks (Async, LWT); on the other, you have OS-level threads, but the
runtime system has a global lock which makes only one thread execute at a
given time. So no parallelism without forking[1] to separate processes.
Moreover, the interactions between an event loop and OS-level threads which
sometimes arise are non-trivial and in my experience very hard to get right,
even with the helpers in Async.

Single-threaded performance is generally good when natively compiled. In a
benchmark I did a few years back, which consisted of traversing the filesystem
with `opendir`, `readdir` and friends, OCaml was minimally slower than C++ and
Nim (when compiled natively) and around Python and Racket when byte-compiled.
It probably would be even faster if I used its imperative features. Looking at
the code today I also see some unnecessary copying of lists, which could be
mitigated. All in all, I think OCaml has a really good performance considering
its high-level semantics. You have to be aware of relative costs of
operations, but if you do, "as fast as C" is certainly attainable. OCaml code
for the benchmark: [https://klibert.pl/posts/walkfiles-
ocaml.html](https://klibert.pl/posts/walkfiles-ocaml.html) and the results:
[https://klibert.pl/statics/images/walkfiled_perf_test1.png](https://klibert.pl/statics/images/walkfiled_perf_test1.png)

[1] Actually, I just checked and it looks that `fork` is not implemented, so
copy-on-write memory sharing is impossible, even on POSIX systems. Docs:
[http://caml.inria.fr/pub/docs/manual-
ocaml/libunix.html](http://caml.inria.fr/pub/docs/manual-ocaml/libunix.html)
[http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Unix.html](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Unix.html)

~~~
gmfawcett
Re-read the page that you linked. Fork isn't implemented on _Windows_ , where
fork doesn't exist anyways. Forking works just fine in Ocaml (on Unixes).

Unix module docs (with fork!): [http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Unix.html](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Unix.html)

------
leshow
Could someone write the equivalent of this in Haskell (assuming the GADTs
ext).

    
    
        type 'a ty = Int : int ty | Bool : bool ty | String : string ty;;

~~~
def-lkb

      data Ty a where
        Int  :: Ty Int
        Bool :: Ty Bool
        ...

------
xvilka
Hopefully multicore OCaml will land into the mainline eventually. In my
opinion it is the biggest issue against Rust or Haskell.

------
ernst_klim
Great, I'm using OCaml for a production code and it's the most pleasant
programming experience I had so far.

------
peeyek
They should focus on developer tooling for wide adoption. More OCaml dev, win
win situation for jane street.

------
jonloldrup
I'm wondering whether Ceylon could be considered a modern day Ocaml
substitute? It has a very strong type system, focus on immutability, a strong
module system and Object Oriented capability. What's missing?

~~~
sgt
I don't think Jane Street would be using OCaml to this extent if it needed a
"modern day substitute". And the language is evolving, which is always a
healthy sign.

~~~
jonloldrup
Okay, wrong wording. However, Ocaml has several 'warts'.
[https://news.ycombinator.com/item?id=9583659](https://news.ycombinator.com/item?id=9583659)

I suggested Ceylon as the 'modern day substitute' in the sense that it has had
the opportunity to learn from mistakes made by the older FP languages. Ceylon
has a very consistent type system and is therefore able to deliver more clear
error messages.

~~~
chillee
Since that user didn't specify them, what would you view as these warts?

~~~
klibertp
It has 3 (4?) different, not very compatible stdlibs, for example. Also 3
tools for syntactic extension, two of which suck incredibly, while the last
one is pretty new. It has 2 (3 if you count Reason) very different syntaxes
defined, even though I've never seen the "light" kind in the wild. The whole
String mutability story is interesting in its own right. I'm sure there's a
lot more.

But note: every single language has warts like this, especially if it's been
developed for a couple of years already. I think OCaml has probably fewer
warts than JavaScript, or PHP, or even Java; but more than Go, or Elixir, or
Scheme. It's still very nice language and toolchain, though, perfectly usable
in many cases - the learning curve may be steep at some points, but on average
it's not that hard to learn, and you gain a lot of benefits if you do.

~~~
yminsky
OCaml isn't without its warts (like any language), but I don't quite think
you've nailed them.

For one, the different stdlibs are in fact highly compatible. Basic types
(option, result, string, int, array, float) are all the same, so code using
different stdlibs works together seamlessly most of the time.

Lwt and Async are a different story, and there is a real incompatibility
problem there.

The syntax extension story is pretty clear and simple: PPX rules the roost,
and the tools for building PPXs are quickly getting better and more unified.
Reason is an interesting variant in the ecosystem, but its existence doesn't
amount to a wart in my eyes. It's an alternative syntax that you can use
interoperably with the rest of the OCaml ecosystem (and Dune makes that
awfully easy.)

------
useranme
Is there anything OCaml can do that no other language can do?

~~~
a0
The most unique feature is the type system which allows you to both model
domain problems effectively and guarantee consistency. This reduces a huge
number of bugs in compile-time.

