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

41–50 of 103 posts

Re: Reason ML toolchain

#41

Post by lilactown »

kbenson wrote: post #32
nv-vn wrote: post #24

Earlier quoted context omitted.

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 Oca…

Are you saying pure Reason,possibly with some JS interop isn't possible? Because that sounds like not using an Ocaml packages to me, which means they aren't a necessity.

He's saying Reason = OCaml. OCaml can be compiled to to either a native executable, native bytecode, or JS.

His comment may sound like a bit of an non-sequitur, but really the confusion comes from: it's not a delineation between OCaml and Reason, but native packages vs. packages that are designed with JS interop in mind.

Some native packages can be compiled to JS (e.g. if they don't rely on C FFI), but many interesting ones cannot. js_of_ocaml's version of this story is much better than bucklescript's, but honestly I haven't explored it that much in either one.

So what you're saying - write pure OCaml/Reason code, with some JS interop, without relying on native OCaml/Reason packages - is certainly possible! And is probably the most common way of writing apps using the ReasonML syntax today.

Re: Reason ML toolchain

#42

Post by jarpineh »

I looked at ReasonML couple weeks back intrigued by Jared's post (referenced in this thread as well) I noticed mentions about OCaml not supporting Unicode. I was wondering what does that actually mean? If you target native you have to find good external libraries for Unicode string manipulation? Or that text handling in OCaml (and thus Reason) is harder compared to facilities in, say, JavaScript and Python?

Other than that bit Reason React looks very promising. My usual use case tends to start with arbitrary JSON source I'd like to build a tool for. Due to strict typing this runs headlong into hurdles that have ended my explorations...

Re: Reason ML toolchain

#43

Post by weberc2 »

nv-vn wrote: post #27
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 ca…

> So in reality, it's a little bit crazy to expect the Reason users to be the ones rapidly changing the toolchain.

That's too bad, because all of the marketing (at least around the time I initially looked into it) was something like "OCaml for humans". The JS bit was mentioned as a footnote, but then when I looked at it, JS was the primary target.

I was half hoping that Reason would fix some problems that keep me (and probably many others from OCaml):

* Fragmented build tooling ecosystem with no outstanding options (ideally the Reason community would build a standard tool that improves on other options)

* Fragmented standard library ecosystem with no outstanding options (ideally the Reason community would standardize on a std lib, but this might be overly optimistic)

* Syntax (obviously this is Reason's target problem, but not the most important issue)

* Parallelism (well, Reason probably would never address this one)

Re: Reason ML toolchain

#44

Post by skybrian »

nv-vn wrote: post #24
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 Oca…

But that's just syntax. As you say, it doesn't mean an arbitrary library written in OCaml will actually run in the browser due to dependencies. It doesn't matter if you can link the code if it won't actually work.

I'm reminded of GWT where there is client-only Java, server-only Java, and portable (shared) Java. It's all Java but you definitely have to keep your desired platform's constraints in mind when looking for a library to reuse.

Re: Reason ML toolchain

#45

Post by kbenson »

lilactown wrote: post #35
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…

I understand what you're saying. Many native OCaml libs are not portable to JS, and you definitely can't port a JS lib to OCaml with the current toolset, which prevents the dream of being able to not care at all about runtime. It's the same dream I've been chasing on the Clojure(Script) side lately as well. I believe you can get close in ReasonML by making a clear distinction between client (JS) and server (native),…

> I believe you can get close in ReasonML by making a clear distinction between client (JS) and server (native), and then maintaining a common module of business logic and utilities that you would want to share between the two.

That was the conclusion I came to as well, but I decided it wasn't worth doing so at this stage. I think eventually the ReasonML ecosystem will grow enough to make this much easier. It's nice that you can use Ocaml libs and Js libs in instances, but I think there are use cases where people mistake can for sufficient, when in those cases it's not.

Ideally this would be solved by pushing Ocaml libs towards JS, but I'm not sure how much attention Ocaml has gotten with respect to we stacks (even the lower end of web stacks). It's unclear to me whether high quality libs exist to push towards JS to all the needs that exist in that space.

Re: Reason ML toolchain

#46

Post by ch4s3 »

enalicho wrote: post #18
bjz_ wrote: post #17

Earlier quoted context omitted.

Reason also has the benefit of Bucklescript which has very high-quality JS output - very friendly to VMs, and the rest of the JS tooling ecosystem. This is something where Elm is sadly lagging quite behind.

Can you quantify this? In what sense is the JS output from Elm lagging behind? What is it about the JS output from Reason that makes it better?

My biggest gripes with Elm are cumbersome JS interop, and the fact that the output for a hello world when gzipped and minified is still 43kb.

Re: Reason ML toolchain

#47

Post by Nelkins »

m0meni wrote: post #4

I'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…

You may want to check out Fable[0] for F# if you haven't already. Syntax will be very familiar, and the interop[1] with JS is really great. There is also a tool to create bindings from Typescript declaration files[2].

[0] http://fable.io/

[1] http://fable.io/docs/interacting.html

[2] https://www.npmjs.com/package/ts2fable

Re: Reason ML toolchain

#48

Post by sridca »

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

And if you are interested in Elm, but felt limited by the language, you may also be interested in PureScript or Haskell.

http://purescript-pux.org/

https://haskell-miso.org/

http://docs.reflex-frp.org/en/latest/

Re: Reason ML toolchain

#49

Post by kbenson »

nv-vn wrote: post #36
kbenson wrote: post #32

Earlier quoted context omitted.

Are you saying pure Reason,possibly with some JS interop isn't possible? Because that sounds like not using an Ocaml packages to me, which means they aren't a necessity.

Pure Reason exists, but you can just use `refmt` to convert any OCaml code to Reason (which isn't even necessary, since they both get compiled to the same thing and are stored in the same syntax tree).

What I was commenting on was the statement that being able to use Ocaml packages is a necessity, and specifically as a rebuttal to my saying being able to use them is a feature.

The implication I get from that is that pure ReasonML to JS without Ocaml packages is not possible, which is why I asked.

There of course may be some difference on what people consider an Ocaml package, but I would consider anything ReasonML comes with as available in the core as not an Ocaml package, even if that's what provides the support underneath it all, as it's now part of the ReasonML spec (and if the Ocaml package was deprecated, they would find some other way to provide the same underlying functionality so the API did not change).

In any case, that statement about it being a necessity confused me.

Re: Reason ML toolchain

#50

Post by anthonybullard »

ch4s3 wrote: post #46
enalicho wrote: post #18

Earlier quoted context omitted.

Can you quantify this? In what sense is the JS output from Elm lagging behind? What is it about the JS output from Reason that makes it better?

My biggest gripes with Elm are cumbersome JS interop, and the fact that the output for a hello world when gzipped and minified is still 43kb.

I get what you're saying - as someone who is very concerned about bundle sizes currently - but if you are using something like Elm door a help world, you are already losing. Elm is for complex, highly dynamic user interfaces that need a high level of durability and maintainability. Toy projects like the one you describe are useful for learning the language and it's patterns, but for practical purposes it's like bringing in a concrete truck to patch a hole in your driveway.

Also, that bundle size is still smaller than react + react Dom. And you get the features of redux and immutable for free plus a solid, statically checked type system.

Post reply on HN