Hacker News Reader

Hacker News

Comment by k_bx | Hacker News Reader

Parent Full thread

k_bx

There's one very important thing that people miss when they mention Elm vs PureScript (or others) which bothers me.

Here's my message: Elm is playing the JS world's game (obeying the rules) and it's winning it!

- you can take a JS dev and they'll be productive in two weeks in Elm

- the compiled code will be smaller than react's

- compilation time is less than in webpack (and compiler's reaction is under 0.2 secs most of the time)

- performance of your app is better

- no runtime exceptions

PureScript and others, unfortunately (at least in many cases), take a different direction: they don't play the game at all, staying in their own, very different one. But hey, they have type-classes!

View on HN

> Elm is playing the JS world's game (obeying the rules)

I disagree, though the meaning isn't clear. Elm is interesting, but it's not part of the JS world, and it doesn't come close.

Just recently, the Norway Railways described their experience with Elm. It was largely positive, but one of the main two negative points was the difficulty to interoperate with JS libraries. They tried it, and failed hard (many runtime errors). BTW, the other pain point was the restrictions on packaging, which is quite orthogonal with the (npm) JS world. https://news.ycombinator.com/item?id=21204761

By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, unlike other ML-family JS languages.

I don't claim Elm to be a part of JS world, and your points about JS interop are correct, it's somewhat difficult if it's heavy, so using Elm as a driving for some big JS library would be a bad idea, while using some small interface for drawing charts or WYSIWYG is ok.

The private packages point is specific to how they do stuff, but I agree that it would be an improvement to allow that from package.json.

> unlike other ML-family languages

I'm curious about this comment, for my current project I chose reasonML over Elm very much because reasonML plays well with old javascript and it plays nice with the rest of the web.

My bundle is very small, compile times fast, and interop with even quite old JQuery libraries is a breeze.

Is there something else I'm giving up that I'm not aware of?

Elm doesn't allow you to call JavaScript code in Elm anymore. The reasoning is to prevent runtime exceptions. Instead, you have to go through something called ports, which is like passing JSON around. That's why there are people who complain about the Elm-JavaScript interop.

Right, when I was first exploring alternatives to Javascript was around the time Elm was removing first class FFI's in favor of ports and it was the primary reason I chose not to use it.

But the poster I responded to was saying that Elm made considerations about the wider web that none of the ML family languages had and I was hoping to find out what those might be since I'm not aware of any non-language advantages of Elm over ReasonML.

What doesn't 'playing by the rules' even mean? It feels like a highly subjective and disingenuous comment. Elm's focus on SPAs is fine and good, but very narrow compared to what JavaScript can do. Elm's port system, it's way to interop with JavaScript, can't do synchronous code which can be a no-go. All of your bullet points apply the same reasons people say to use ReasonML. PureScript offers the same safety if you 'play' by its rules.

I do Elm at my job every day, but it has serious competition.

By "playing by the rules" I meant that Elm doesn't give up the big considerations that lie outside of the purely linguistic features, I've listed some of them.

PureScript is a tremendous language, and I'd be happy to see it more widely used, and your points about JS interop and SPA focus are true of course, but I would argue that the step for ditching FFIs are better for some of the same reasons that were listed.

I think you might be missing part of the philosophy. If you take a look at purescript-web-dom, most of the browser APIs have merely been wrapped. This saves you work and you can use it if needed, but it is encourage to use this as a foundation to build better APIs/DSLs (heck, steal them from Elm). Elm does a similar thing under the covers, and they release an often better API than the browsers, however, you can't use this intermediate representation to build alternative APIs and many times you have to wait years for anything to even pop-up in elm-explorations because nothing is satisfactory if it doesn't improve upon the browser's standard. This philosophy has its pros and cons, and while sometimes the APIs can be clunky in PureScript because it's just wrapping the browser API, I never felt straight-up blocked by a missing feature.

With Elm you can't, for example, use the browsers Intl API to get plurals, currencies, dates, etc. This is the type of thing you want to partially apply/instantiate with your locale, then use it synchronously at the view level with your model for display. You just don't have the access to do this because a proposal must be made and approved by the Elm team. It'll probably be good API, but you'll be SOL in the meantime (for possibly years). This isn't a dev cycle that works for every person, team, or project.

This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.

You're mixing your "playing by JS' rules" point with just general Elm features. Faster compilation speed, faster executables, and smaller executables are not JS' rules, they're just generally desirable things to have. "Faster than Webpack" and "no runtime exceptions" are certainly not the JS world's rules (does Purescript have runtime exceptions?). That a typical JS developer can get up to speed quicker in Elm seems very nebulous to me; why? Could you elaborate more on what you're talking about? How is Purescript not playing by JS rules, other than being (I assume) slower than Elm?

> you can take a JS dev and they'll be productive in two weeks in Elm

i’ve never been a big fan of these sorts of assertions. not everyone picks things up at the same rate.

I wonder of what of those points would be impact had typeclasses been implemented into ELm.

It would be a bit of a rabbit hole, as many common uses of typeclasses in Haskell require HKT, which Elm doesn't have. Typeclasses per se could be bolted on to Elm relatively easily, but I suspect that adding HKT without compromising Elm's other advantages (e.g. fast compiles, good error messages) would be quite tricky.

That's a good question! Some things are hard to predict (compile times), some are easier (their abuse would grow, very soon Elm would loose the first "newbie friendliness" point).

Yeah, I think typeclass by themselves are not harmful, but then common libraries will be full of them, providing nice error messages would be harder, and then you might attract too much of the category theory folks declaring functors everywhere and scaring the newbies. (Nothing against category theory, but it's not really newbie friendly which is what Elm tries to be)

Interestingly enough, I think that Category Theory is more of a saviour here than anything, reason being this: most of the harm from over-using type classes comes from the cases when their usage can be avoided, and a general rule of thumb in the Haskell world is now this: if there are no laws that your type-class is bringing, avoid using it. Thus, Functor is ok, but "HasStatsField" stuff is not really.

HasField typeclass was recently added to GHC. It has no laws.

https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

Luckily, all that stuff will be outdated with somewhat proper records https://github.com/ghc-proposals/ghc-proposals/pull/282

The RecordDotSyntax extension is just syntactic sugar for the HasField typeclass. It doesn't make HasField "outdated". Anyway, the HasField typeclass (with the proposed change to support field updates[1]) does have at least one law:

    uncurry ($) (hasField @x r) == r

or expressed with the getField and setField wrappers:

    setField @x r (getField @x r) == r

[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

Reply on news.ycombinator.com