Thanks for the thoughts. I would definitely not call Reason a new language, but rather a new interface to an existing language that is already great. Not all languages make it easy to provide such an interface, but OCaml did, and the timing made sense.

I like the syntax cleanups. What's the advantage of using the existing OCaml toolchain over using an LLVM backend? Expediency and interop with Facebook's other OCaml libraries? From what I have read, the OCaml compiler only does basic optimizations and the runtime has poor multithreading support.

Facebook has many projects that are already written in OCaml, and Reason provides a path forward for seamlessly, and incrementally moving projects over to the new syntax/style.

Feel free to take a look at some Reason in the wild, used inside of the Infer project at Facebook:

https://github.com/facebook/infer/tree/master/infer/src/IR

Apart from that, although syntax is the "user interface" to a language, and user interfaces are very important, there really is so much to a language beyond the syntax. I see Reason's syntax as a way to make the really good parts of OCaml exposed to a wider audience, while making existing OCaml developers more productive in their editors.

Some things you might appreciate about OCaml's core language (which Reason provides a new interface to):

- World class pattern matching.

- Excellent type inference.

- Bare metal compilation without a VM, but alternatively the ability to compile into JS.

- Great predictable performance, even without a ton of performance optimizations (because the runtime is so simple), but take a look at 4.03 which includes a new F-lambda optimization pass. Even without F-lambda the perf is competitive with other systems languages, and F-lambda buys you another good 10-30% reduction in CPU or so.

- Multicore support is progressing. Here's a PR from today to add multicore support to the native backend (https://github.com/ocamllabs/ocaml-multicore/pull/47)

Cool. Thanks for the background. I'll take a look at the Infer code. :)

It's important to realise that an LLVM backend is not a panacea -- the OCaml native code generator is highly optimised for the calling conventions and OCaml GC already. LLVM's IR doesn't quite track values at the same abstraction level as OCaml so some features such as exceptions become very expensive if mapped onto LLVM without changes to the IR.

Another major recent advance in OCaml 4.03 (released last month) is the flambda middle layer -- basically an epic inlining and allocation elision pass. See https://blogs.janestreet.com/flambda/ for more on it, but it's already giving 10-20% performance improvement on real world code.

Multicore is also coming soon -- see https://ocaml.io/w/Multicore for a summary of activity there.

LLVM may be better at generating opcodes, but a lot of things are happening between syntax and opcodes, especially type inference, type checking and inlining (including cross module and now cross functors).

Actually, if ocaml "optimized" compiler have shown anything, it's that micro optimizing instructions and register allocation is not as important as once believed. Indeed, for long amongst "sophisticated languages" Ocaml "optimized compiler" was renowned at the same time for the speed of generated code and for the simplicity of its code generation pass, lacking many advanced features found in ghc for instance.

reason : ocaml :: lfe : erlang might be an apter comparison. it adds a new syntax parser, but not a new language. from their docs:

> The OCaml compiler is organized into several stages, which are exposed as libraries. Reason replaces part of the compiler toolchain with a completely new syntax parser that is more approachable, while still fully compatible with the rest of the compiler. Reason also implements a new source printer which integrates into your IDE and the new custom REPL.

I always liked ML family PLs, but my problem with OCaml is lack of good stdlib. This is why I never invested a lot of time in to it sadly. Reasons looks like a more solid out of the box ocaml distribution which I actually like a lot. Will play with it.

Glad to hear it! We've also tossed around the idea of having a precompiled standard lib come with it upon installation. We're certainly not looking to increase the number of standard libraries, when there's already so many to choose from, but including/pre-building/curating is certainly within the scope.

This would be so interesting! I don't know any other language that has made this before. But if the intention is to increase the reach of OCaml then if sound like a great plan.

Have you ever tried the Jane Street standard libraries?

yeah, but it's not the standard library. this is my problem. what about compatibility with the other tools/libs?

I think for the most part the community is standardizing on using Core as though it was the standard. As an example: Real World OCaml, for instance, assumes Core is installed (note: I believe it is coauthored by one of the Jane Street employees).

A similar language might be Haxe, which can target C++, Java, C#, PHP, JavaScript, Python, Lua, and Neko languages, and make use of the tooling/build chain for those languages.

So you can abstract the syntax from the runtime, but the semantics are often different per target - e.g. accessing the filesystem in Node.js will be different to C++, due to the non-blocking I/O mechanism.

As an aside, the Haxe compiler is written in OCaml. I think there'd be a delicious juxtaposition if it was re-written in Reason. Writing Reason to generate OCaml to create Haxe to generate Java to generate bytecode...

> As an aside, the Haxe compiler is written in OCaml. I think there'd be a delicious juxtaposition if it was re-written in Reason. Writing Reason to generate OCaml to create Haxe to generate Java to generate bytecode...

It should be easy to convert the Haxe compiler into Reason with refmt. Maybe unless if it's using camlp4 syntax extension... But I guess you could add a camlp4 pass before running refmt.

Ah, I forgot about Haxe. Someone correct me if I'm wrong, but isn't Haxe essentially a transpiler with its own stdlib? I think Reason is different is that it explicitly integrates into the OCaml build process.