Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reason ML toolchain

khoanguyen.me

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Reason ML toolchain

#21

Post by kbenson »

I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great. Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed. This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end.

Unfortunately, what you appear to have currently is that a lot of the tools and utilities you would want to use in ReasonML are written in either JS of Ocaml, and reply on the interop when you target that platform. Want an ORM? There's a couple, but they are all targeted at Ocaml, so you either compile to native and link or try to port the Ocaml source of it to ReasonML (maybe automatically?) and maintain it. Want a web router/framework? There's a lot written in JS, but you'll be configuring and writing some JS most likely to get it to work, and no compiling that natively. This is a recurring theme. Most robust larger packages are in one language or another, which causes problems for anyone wanting to leverage the inherent advantages of both target formats.

What it seems to come down to is that Reason needs a whole lot more software written in Reason so it's more flexible. Being able to use Ocaml and JS packages is a feature and liberating, nut having to use Ocaml or JS packages ends up putting constraints on your project. ReasonML has a lot of promise, but at least for what I was excited about, it can't deliver. Yet.

Re: Reason ML toolchain

#22

Post by ihm »

kbenson wrote: post #21

I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great. Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed. This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end. Unfortunately, what you appear to h…

js_of_ocaml[1] is an ocaml to JavaScript compiler that can actually handle the entire ocaml language (because it compiles ocaml bytecode to JavaScript). Sounds like it’s more what you’re looking for than Bucklescript (the ocaml to JavaScript compiler Reason uses by default.) Since Reason is just an alternate syntax for ocaml, you can use it with js_of_ocaml as well.

[1]: https://github.com/ocsigen/js_of_ocaml

Re: Reason ML toolchain

#23

Post by thangngoc89 »

kbenson wrote: post #21

I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great. Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed. This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end. Unfortunately, what you appear to h…

Hey author here,

I think I failed to explain about this in the article. OCaml and ReasonML is the SAME language with different syntax. You don't need to worry whether the library is written in OCaml or ReasonML as long as your build tool support both ReasonML and OCaml.

Re: Reason ML toolchain

#24

Post by nv-vn »

kbenson wrote: post #21

I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great. Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed. This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end. Unfortunately, what you appear to h…

Any Reason code can be linked to OCaml code, because OCaml = Reason. In fact, they are only syntactically different. That is, Reason is an alternate syntax for OCaml. BuckleScript/js_of_ocaml can be used in either language, which is to say that any OCaml code can be compiled to JS libraries assuming there are no dependencies that will fail on JS (no need to convert to Reason code or anything).

> Being able to use Ocaml [...] packages is a feature

It's not, it's a necessity. OCaml and Reason are the same language; it's not like Erlang vs. Elixir which both run on BEAM.

Re: Reason ML toolchain

#25

Post by thangngoc89 »

mlevental wrote: post #16

started from quickstart and now we're here: ``` let message = "hello"; print_endline message; /* Prints "hello" */ ``` output $ bsb -make-world -w >>>> Start compiling Rebuilding since just get started ninja: Entering directory `lib/bs' [1/2] Building src/demo.mlast FAILED: src/demo.mlast /usr/local/lib/node_modules/bs-platform/lib/bsc.exe -pp "/usr/local/lib/node_modules/bs-platform/lib/refmt3.exe --print binary" -w…

`print_endline message` is version 2 syntax. Could you point me to the exact location so I can send a PR to fix it?

Re: Reason ML toolchain

#26

Post by nv-vn »

RubenSandwich wrote: post #2

This 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.

Is the OCaml compiler really the same as those others though? I'd say it's more complex than that. It has a very large middle-end that most compilers don't. Things that are pluggable so far:

- Lexing/Parsing (ReasonML) - Preprocessing (PPX) - Backend (BuckleScript/js_of_ocaml)

Other parts of the compiler (not as pluggable?):

- Typechecking (which is really what makes it OCaml; TyPpx allows some changes) - Semantics (can be overridden with PPX somewhat) - Optimizations/middle passes (things like Flambda)

Re: Reason ML toolchain

#27

Post by nv-vn »

weberc2 wrote: post #7

Last 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. :(

Reason targets JS programmers. OCaml's toolchain is great honestly, it just seems like ~85% of Reason users are more focused on the JS parts of the language, so what happens is the new users from Reason don't really do much to contribute to the native toolchain (though any libraries they write can mostly be used with the native toolchain, which is really nice!). The other thing is, most of the compiler programmers came to OCaml because it was an ML, and I think for the most part this group will continue to use the ML syntax and self-selects for the group that prefers it. So in reality, it's a little bit crazy to expect the Reason users to be the ones rapidly changing the toolchain. That said, this will continue to bring more attention to OCaml and hopefully more funding that can help solidify things like multicore, modular implicits, and everything else making its way through the compiler development pipeline at 2mph.

Re: Reason ML toolchain

#28

Post by thangngoc89 »

ihm wrote: post #22
kbenson wrote: post #21

I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great. Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed. This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end. Unfortunately, what you appear to h…

js_of_ocaml[1] is an ocaml to JavaScript compiler that can actually handle the entire ocaml language (because it compiles ocaml bytecode to JavaScript). Sounds like it’s more what you’re looking for than Bucklescript (the ocaml to JavaScript compiler Reason uses by default.) Since Reason is just an alternate syntax for ocaml, you can use it with js_of_ocaml as well. [1]: https://github.com/ocsigen/js_of_ocaml

Yes. js_of_ocaml has different goal with Bucklescript. I addressed this in article. Funny fact, Bucklescript could be compiled with js_of_ocaml for running on the web. More details: https://github.com/glennsl/bs-in-a-box

Re: Reason ML toolchain

#29

Post by myth_drannon »

osteele wrote: post #15

If you're interested in ReasonML, you may also be interested in Elm http://elm-lang.org/ . Coming from JavaScript / React / Redux / Flow, ReasonML initially looked more familiar, but I still found Elm easier to pick up. Elm has a more unified feel. ReasonML read to me as an assemblage of components — each of them high quality, and expertly integrated, but it still felt like more different pieces all to learn at once.…

Facebook and Bloomberg, two large gorillas throwing their weight behind ReasonML+Bucklescript tooling. Elm is mostly Evan (with support of RedInk)working on the core/tooling with a lot of help from Richard Feldman on general ecosystem. No surprise here that ReasonML is gaining momentum fast.

Re: Reason ML toolchain

#30

Post by rehemiau »

k__ wrote: post #19

Hopefully they'll get theit async story sorted out fast. That's the only thing holding me back right now.

Could you elaborate on that? Do you mean async on frontend as in javascript async/await or do you mean async on the backend as in threads etc?
Post reply on HN