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

51–60 of 103 posts

Re: Reason ML toolchain

#51

Post by splintercell »

weavie wrote: post #34
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.…

Conversely, if you are interesting in both Elm and ReasonML there is Bucklescript-Tea - https://github.com/OvermindDL1/bucklescript-tea/ . The Elm architecture ported to Bucklescript.

Is it as fast as Elm?

Re: Reason ML toolchain

#52

Post by laylomo2 »

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…

What that means is that the language itself has no built-in constructs to distinguish Unicode, or any other encoding by default.

OCaml's string type is more akin to an array of chars in C, in that it just represents a series of bytes. There's nothing about the string type that describes the contents of the bytes. So while you could put ascii in there, when you to print the contents, it's up to the terminal emulator to decide how to interpret those bytes.

One thing which you can do is include Unicode characters and save them in an OCaml source file. The string type will capture the byte representation just fine.

If you want to enrich the string type to also include format information, you might have to look for other libraries.

And, one last point about the string type: traditionally the string type allowed for mutation. In the last few years this behavior has been deprecated, and in the latest version of Ocaml (4.06), a compiler flag -safe-string has been enabled by default. This makes string immutable, and the traditional behavior has been moved to a new type called bytes.

Re: Reason ML toolchain

#53

Post by splintercell »

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/

I have the same concern, what is the performance of these frameworks in comparison to Elm? Elm is super fast compared to React and Angular [1], but what about these frameworks?

1. https://www.codementor.io/rudolfolah/elm-vs-react-developmen...

Re: Reason ML toolchain

#54

Post by didibus »

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.

Re: Reason ML toolchain

#55

Post by saosebastiao »

How well does Reason interop with OCaml libraries? Also, how will it work with upcoming changes in the OCaml language that require changes to the runtime (like the multicore runtime, possibly modular implicits)?

Re: Reason ML toolchain

#56

Post by frou_dh »

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.

As I understand it, the upcoming Elm 0.19 compiler will do dead code elimination for the output bundle.

Re: Reason ML toolchain

#57

Post by ch4s3 »

anthonybullard wrote: post #50
ch4s3 wrote: post #46

Earlier quoted context omitted.

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

Yeah, bundle size isn't a real deal breaker, but it does make it a bit harder to roll into an existing project in small chunks. My main issue is the interop portion.

Re: Reason ML toolchain

#58

Post by Royalaid »

Nelkins wrote: post #47
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

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.

Re: Reason ML toolchain

#59

Post by didibus »

skybrian wrote: post #44
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…

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…

You can try Doppio and JavaPoly. Its a full JVM running on JS, and works with most Java libraries that don't do things which would go against what the JS sandbox is allowed to do.

Re: Reason ML toolchain

#60

Post by blurbleblurble »

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! Looking forward to playing with ReasonML/OCaml!

Post reply on HN