3 ms·
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 la
by jordwalke 10y ago
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.
- cpeterso 10y agoI 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.
- jordwalke 10y agoFacebook 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 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 https://github.com/ocamllabs/ocaml-multicore/pull/47)
- cpeterso 10y agoCool. Thanks for the background. I'll take a look at the Infer code. :)
- avsm 10y agoIt'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/ 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 https://ocaml.io/w/Multicore for a summary of activity there.
- rixed 10y agoLLVM 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.