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

81–90 of 103 posts

Re: Reason ML toolchain

#81

Post by aaron-lebo »

Royalaid wrote: post #58
Nelkins wrote: post #47

Earlier quoted context omitted.

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

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 functional language, you've gotta bring along those immutable datastructures somehow, and 5k lines of Clojure is gonna output greater than 5k lines of JS.

Re: Reason ML toolchain

#82

Post by _0w8t »

sridca wrote: post #48
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/

Initially for me Elm felt like a toy language that serious folks should ignore in favor of PureScript and similar. But then after reading code for various Elm applications I realized that I can grasp how things work just by reading the description of the state. Code was just filling details that can be ignored on the first reading. This does not happen with other functional languages when the code ended up passing various important bits of the state in lambdas of callbacks making understanding of the whole much harder.

Re: Reason ML toolchain

#83

Post by yawaramin »

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…

Keep a watch for the new Reason standard library, it will bring some stunning reductions in output code size. I mean, right now the output code size is about as minimal as you can get while looking like hand-written JS ... but what's coming might blow all the other immutable libs out of the water thanks to optimisations it can do using static typing information.

Re: Reason ML toolchain

#84

Post by yawaramin »

aaron-lebo wrote: post #69
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…

One place you can see this in action is that [ ] are lists and [| |] are arrays. JS favors arrays, OCaml lists, so you either write dsls with [| |] (ugly), or you import a module and convert from lists to arrays and your bundle size goes up 80 KB (don't recall if minified or not). I was surprised to see Reason continue with this syntax. The idiomatic approach for either side is suboptimal unless I'm missing something…

Hi, I'm pretty sure a tree-shaking bundler like Rollup can wipe out most of that bundle size by using only the list functions you need. Then again, if you need to use arrays, use arrays, [|1, 2, 3|] is not actually that bad–you get used to it pretty quickly.

Re: Reason ML toolchain

#85

Post by yawaramin »

myth_drannon wrote: post #29
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.

One thing to remember is that Reason and BuckleScript are rather small projects, with not that many people employed to work on them. Their combined 'manpower' is not that much more than Elm's right now.

What they are cleverly leveraging is the twenty years of solid type theory (a sound type system), language design (more powerful pattern-matching, functions, syntax sugar), and engineering practice (the OPAM ecosystem) that has gone into OCaml.

This is why Reason/BuckleScript are able to punch above their weight class.

Re: Reason ML toolchain

#86

Post by jordwalke »

blurbleblurble wrote: post #60

Since a lot of people are coming to OCaml for the first time through ReasonML, maybe this gotcha might be helpful: I was having a really hard time doing `npm install -g bs-platform`. I kept getting "linking" errors that I didn't understand, since I'm new to Ocaml. It turned out that I needed to get rid of my ~/.opam directory. I did `mv ~/.opam .opambk`, then `npm install -g bs-platform` suddenly worked! Sweet! Looki…

Thanks for the tip. Also, we are working on making it easier to isolate opam packages and npm packages side by side in one development environment so that problems like this are avoided. This allows you to build a project that depends on opam packages for build time tooling inside your JS projects. That project is called esy, and it’s a young addition to the ecosystem but something I’ve been using to greatly increase my own productivity for a while now. It will not make BuckleScript compile opam packages (that is not BuckleScript’s goal) but it will at least make the two ecosystems coexist simultaneously.

Re: Reason ML toolchain

#87

Post by yawaramin »

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've done cross-platform development with Scala (JVM/JS). I'll tell you, with all the tooling support (sbt) that Scala has right now, it's not all that much easier than what you can do with Reason.

Typically, you get libraries like `foo-scalajs` and `foo-scala` which are basically cross-compiled from a single codebase which is divided into three major parts: common, JS, and JVM.

With Reason you can do the same thing (in fact people have). On top of which, Reason's functors (higher-order modules) allow you to write for multiple platforms in a very clean and decoupled way. They are a great, great boon for software engineering and folks like e.g. the MirageOS have used them to great advantage to target say the unikernel and Unix environments for their apps.

Re: Reason ML toolchain

#88

Post by yawaramin »

_delirium wrote: post #3

Thanks, 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…

If you want to potentially develop for native, make sure to install the OPAM toolchain, it will give you access to the existing OCaml native ecosystem.

Reason is also easy to install from OPAM https://reasonml.github.io/docs/en/global-installation.html#...

Remember that BuckleScript is a separate thing which you can get any time with just `npm install --global bs-platform`

Re: Reason ML toolchain

#89

Post by yawaramin »

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

Re: Reason ML toolchain

#90

Post by [deleted] »

k__ wrote: post #37
rehemiau wrote: post #30

Earlier quoted context omitted.

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?

The first. As far as I know OCaml and JS have stuff to handle this (lwt, promises, event-loop etc.) but the usage in the "front-end" isn't so nice ATM.

[deleted]
Post reply on HN