HN Explorer

Ask HN: What should I learn in 2019 – Elm, PureScript or ReasonML?

10 points by akritrime ↗ HN
I want to start the year by making an effort to better understand FP. I also want to try something different on the frontend for personal projects. So which one of these would you personally choose and why? Also if you are already using one of these, why?

PS: I have seen people not recommending PureScript unless you have experience with Haskell. I won't say I am experienced with it (which I guess is evident because I do want to get better in FP) but I am a bit familiar with it.

7 comments

[ 4.2 ms ] story [ 27.2 ms ] thread
Pako
Elm is kinda limited in the sense that it really only works for UI. You can't use it outside of that. It also doesn't come with all the nice advanced features Purescript has which also makes it "easier" for beginners in my opinion: you don't have to learn as many foreign concepts to get productive. For example I believe I hadn't read "Monad" in the Elm docs even once.

Purescript on the other hand is more advanced and can run anywhere JS does (mainly web and node). FFI with JS is a lot easier than what Elm provides too. It has a better type system but arguably a worse compiler in the regards to error messages. Elm on the other hand has an amazing compiler: thanks to its more restricted nature it can mostly figure out what you were trying to do and give you really helpful tips.

Unfortunately I haven't used ReactML yet.

[deleted]
(comment deleted)
[deleted]
(comment deleted)
[deleted]
(comment deleted)
akritrime
Are the error messages as bad as Haskell? One of the primary reasons I shifted my focus from Haskell was because of the errors generated by the compiler were not at all helpful when you are learning on your own, especially in contrast to something like Rust.
Pako
I'm not too sure about that because I haven't used either in some time unfortunately. I tried some stuff on their online REPL. From what I gathered Purescript is doomed to produce more "unwieldy" error messages because of the more complex type system.

Take this definition for example: ` some = drop (Just 5) [1,2,3,4,5,6] `

Purescript isn't even doing _that_ bad in this case: it complains that `Maybe Int` doesn't match `Int` but then goes on talking about checking if `Maybe t0` is "at least as general as" `Int` which will probably be useful information for an experienced developer but not newcomers. This is, at least from what I experienced, what happens most of the time with Purescript: you get way too much information with way too many details.

Compare this to an error produced by the Elm compiler:

>-- TYPE MISMATCH ---------------------------- Main.elm

>The 1st argument to `drop` is not what I expect:

>8| List.drop (String.toInt userInput) [1,2,3,4,5,6]

> ^^^^^^^^^^^^^^^^^^^^^^

>This `toInt` call produces:

> Maybe Int

>But `drop` needs the 1st argument to be:

> Int

>Hint: Use Maybe.withDefault to handle possible errors.

yawaramin
Let me put in a good word for ReasonML. It has a fast, efficient JavaScript (ES5) compiler and makes it easy to scaffold (one command) and run a React project. It also provides a well-thought-out and precise JavaScript binding DSL. Unlike the other two, it can compile to native executables as well as JS (with some caveats, and the Reason team is building an npm-inspired workflow around that with the `esy` tool).

Also different from the other two and a feature that I find hugely convenient, you don't have to specify all the imports before you can use them. In ReasonML, all imports are automatically visible everywhere throughout the project. For example, if you write this in Reason:

    let abPath = Node.Path.join([|"..", "a", "b"|]);
The compiler will generate the following JS:

    var Path = require("path");
    var abPath = Path.join("..", "a", "b");