Reason ML toolchain
khoanguyen.me
Reason ML toolchain
1–10 of 103 posts
Re: Reason ML toolchain
#2This is a small nitpick but the line: "OCaml's compiler is pretty unique, it's a set of pluggable parts that can be replaced and used together." is inaccurate. Most modern compilers are broken up into backends and frontends now, e.g. LLVM, JVM, .NET, etc.
Re: Reason ML toolchain
#3Thanks, this was helpful as someone who's interested in this set of tools but hasn't been following closely enough to understand how they all fit together (e.g. why there's both js_of_ocaml and Bucklescript, and how ReasonML fits into this).
For my own needs, it still seems unclear which way I should go though. The attractive thing about the tools to me is that you can write code that compiles to native and web, in a more or less MLish way (which I like). But it seems like either route works for that. I could just write OCaml, using the regular native toolchain for native compilation, and either Bucklescript or js_of_ocaml to compile to web. Or, I could use the ReasonML toolchain instead. If I'm not primarily a JS dev, is there a reason to pick one or the other? The syntax differences so far don't jump out at me as exciting enough to be decisive. I guess I could try a small side project in each and see how it goes.
Re: Reason ML toolchain
#4I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code.
That said, I recently tried rewriting some code, specifically a canvas-based game, in Reason, and while the language itself was amazing, the interop with the mutable JS canvas API was really annoying. To be honest though, not sure if games is what Reason is meant for so it's not a big deal. It's a great fit for React, which really leans heavily on the functional paradigms that Reason promotes.
Also given that FB has rewritten 50% of messenger in Reason, I don't see it dying any time soon. So here's hoping that it keeps growing and the tooling improves. I'd definitely like to see it become more beginner friendly, and additionally, I'd like to better understand how to interop with existing OCaml libraries and target the native platforms.
Re: Reason ML toolchain
#5Thanks, this was helpful as someone who's interested in this set of tools but hasn't been following closely enough to understand how they all fit together (e.g. why there's both js_of_ocaml and Bucklescript, and how ReasonML fits into this). For my own needs, it still seems unclear which way I should go though. The attractive thing about the tools to me is that you can write code that compiles to native and web, in a…
I think why you'd pick Reason over OCaml boils down to whether you prefer the Reason syntax more, and perhaps that it'll have more mindshare than OCaml in the future. I think the question is similar to why you'd pick Elixir over Erlang.
Re: Reason ML toolchain
#6I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…
I found the interopt a bit cumbersome too, but I guess this is what you have to pay for a 100% typed codebase :/
I saw some people wrote games with Reprocessing, maybe this helps.
Re: Reason ML toolchain
#7Last time I tried Reason, it seemed like the OCaml toolchain was all but neglected. For whatever reason (no pun intended), it seems like it's assumed that Reason only targets JS in practice. It seems like the best way to target the server or desktop is by way of Node. :(
Re: Reason ML toolchain
#8Thanks, this was helpful as someone who's interested in this set of tools but hasn't been following closely enough to understand how they all fit together (e.g. why there's both js_of_ocaml and Bucklescript, and how ReasonML fits into this). For my own needs, it still seems unclear which way I should go though. The attractive thing about the tools to me is that you can write code that compiles to native and web, in a…
It's not just about languages. Try out both communities and see which you might prefer to interact with in the medium/longer term. As you suggest, small side projects with each would be a good way to go.
Re: Reason ML toolchain
#9I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…
I found the interopt a bit cumbersome too, but I guess this is what you have to pay for a 100% typed codebase :/ I saw some people wrote games with Reprocessing, maybe this helps. https://github.com/Schmavery/reprocessing
Reprocessing looks amazing, and I might give it a second try now. Thanks!
Re: Reason ML toolchain
#10This is a small nitpick but the line: "OCaml's compiler is pretty unique, it's a set of pluggable parts that can be replaced and used together." is inaccurate. Most modern compilers are broken up into backends and frontends now, e.g. LLVM, JVM, .NET, etc.
Hey author here,
I'll look into this and update the post accordingly. Thank you