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

101–103 of 103 posts

Re: Reason ML toolchain

#101

Post by jarpineh »

yawaramin wrote: post #89
jarpineh wrote: post #42

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

The standard Unicode library in native OCaml is Camomile https://github.com/yoriyuki/Camomile (docs at http://docs.mirage.io/camomile/index.html –unfortunately, it's pretty bare-bones). If you're targeting JavaScript with Reason/BuckleScript, e.g. making a ReasonReact app, you will automatically get Unicode support for strings if you use the {j|Unicode string literal|j} syntax (specially provided by BuckleScript).

Ah, good to know. Main point is that Unicode is not a problem however cumbersome it might get.

Re: Reason ML toolchain

#102

Post by kbenson »

didibus wrote: post #54
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…

> Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed A lot of the JVM languages allow for this. Kotlin, Scala, Clojure and Fantom come to mind. They all can compile to JS also, allowing for code reuse between frontend and backend.

Well, sure, but ReasonML also natively supports JSX, has am included reason-react package and has Facebook behind it. To me that signals not just that it targets JS, but that it targets JS in a way and with tooling and abilities that convey advantages to using it for web development.

Some or all of the other languages you mentioned might as well, but if they do I'm unaware of it.

Re: Reason ML toolchain

#103

Post by iLemming »

aaron-lebo wrote: post #81
Royalaid wrote: post #58

Earlier quoted context omitted.

Generally when it comes to interoperability with JS the problem stems from assumptions made by the people designing the JS APIs and what is idiomatic in the compiles-to-js Lang. Clojurescript, Reason, Purescript, and Elm all have a specific way they want to work and the browser APIs go against that. If anyone has any advice on how to help this I am all ears but writing garbage interop code gets old.

I came to this conclusion over the weekend. Really wanted to use one of those compile to JS languages, but after doing some interop and looking at their output, you're fighting the browser. Even Clojurescript, which is supposed to have has great code elimination will produce much bigger outputs then regular JS. One way to look at it is immutable.js minified is 55 KB. That's about 5,000 lines of JS. If you're using a…

don't forget Clojurescript employs Google Closure compiler that has the best in the market dead-code elimination. Code on prod can be pretty small.
Post reply on HN