Discussion: Elm vs PureScript

[srid]

Some links to interesting discussions here: https://twitter.com/ravi_mohan/status/784246016555884544

[saurabhnanda]

@HappyAndHarmless any first hand accounts from your side about Elm or Purescript?

[srid]

@saurabhnanda Not yet. First getting a hang of Haskell. I imagine it would take a while before I get my hands dirty on PureScript.

[srid]

In the process of writing a mancala game in Elm I came across two pain points with the language and community that makes me consider just using PureScript for personal projects henceforth:

• The lack of type classes can become annoying once the project becomes sufficiently big (more on this; ref).

• The Elm culture is mostly geared toward converting JavaScript developers, and as such much of the language decisions do not appeal to me. elm-format is one such example (for example, see the discussion on tab size; ref), and the lack of where clause is another (ref).

More discussion on this at HN; ref

[nmdanny]

It seems to me that Purescript is better than Elm for several reasons: Pros:

• Type classes, rank N types, higher kinded types, functional dependencies, extensible effects, and more features to the type-system are likely to be added(thus bringing it closer to Haskell)
• Generics, allows deriving instances and reducing boilerplate.
• More flexible/powerful interop (but potentially unsafe/unsound)

Cons:

• Less popular than Elm, and thus fewer libraries are developed in it.
• Elm seems to have a slightly better toolchain (package management, formatting, editor integration), while Purescript depends on the JS ecosystem mess (NPM,Bower,webpack/gulp, etc)

Not sure if pro/con:

• Less opinionated on UI (e.g there's Thermite, Halogen, Pux, raw DOM manipulation via effs, and more)

I think that a more interesting discussion would be between Purescript and GHCJS

[saurabhnanda]

The lack of type classes can become annoying once the project becomes sufficiently big (more on this; ref).

Any first hand example that you can share?

[srid]

Any first hand example that you can share?

I can share two examples from the same project.

1. Lack of type classes means no monads, binds and do-notations, which lead to ugly code like the following:

setSeeds : Int -> Int -> Board -> (Maybe Board)
setSeeds idx seeds board =
  lookup idx board
  `Maybe.andThen` (\pit -> Just <| Array.set idx { pit | seeds = seeds } board.pits )
  `Maybe.andThen` (\newPits -> Just { board | pits = newPits })

validateF : (a -> Bool) -> a -> Maybe a
validateF f v = if f v then Just v else Nothing

sow : Player -> Int -> Board -> Maybe Board
sow player idx board =
  let
    spread seeds fromIdx board = Just board
  in
    lookup idx board
    `Maybe.andThen` validateF (\pit -> player == pit.player) 
    `Maybe.andThen` (\pit -> setSeeds idx 0 board `Maybe.andThen` (\b -> Just (pit, b)))
    `Maybe.andThen` (\(pit, b) -> Just b

2. No type classes means I had to create lambda expressions (with its own disadvantages) to polymorphically work on otherwise disparate diagram shapes

---

Above all unlike the Haskell community I noticed behaviours of bumptious nature (one of which was ironically in the name of upholding couth) in the Elm community.

[srid]

@nmdanny I think that a more interesting discussion would be between Purescript and GHCJS

I would be interested in that. A notable advantage of GHCJS for me is that you can use Haskell libraries, such as the Diagrams package (just need a new backend).

[BartAdv]

PureScript vs GHCJS: PureScript is currently lacking an higher order FRP library, and it might not change soon. PS works on top of JS runtime, and it's lacking weak references which are crucial for such implementation. Check sodium-typescript to see what workarounds were needed to implement it.

[sudhirvkumar]

@BartAdv Can you explain about

PureScript is currently lacking an higher order FRP library

We are using PureScript Pux and Thermite is something we are exploring for Web. Thermite is working great for Mobile Development.

[BartAdv]

Yes, that's not like saying the lack of higher order FRP means your libaries are crippled, they will still work great, they will just offer different way of approaching things. I'll just link the similar question asked about the reflex-dom, as it is not that easy to explain both approaches and the differencies between them without actually trying both and seeing which one you're more comfortable with:

https://github.com/reflex-frp/reflex-dom/issues/113

[sudhirvkumar]

@BartAdv

Thermite is awesome for defining everything as Spec's and React is in the background. React has one of the highest performance and React Fiber is going to make things even better!

http://isfiberreadyyet.com/ as of now... 95.1% is done

Regarding Elm vs PureScript which is what this discussion all about.

Elm we need to write a lot more boiler plate code compared to PureScript. Especially JSON decode and encode. We have worked with Elm in a client Project and we were much more happy working with PureScript... so we ended up migrating to PureScript from Elm.

There are a lot of libraries for almost anything... and if there is anything missing then we will be happy to build those things which we need.

Also, We have RNX (https://github.com/atomicits/purescript-rnx) which is for developing React Native Applications. Which we are using for a client project.

For us PureScript is a Win-Win!

We loved Elm... but there are a few issues...

Especially... not being able to collaborate or communicate with Elm developers... they haven't been very friendly... and ofcourse... Evan will disappear for a few months and work on things while PR's will become stale. And developing custom packages with Native code and contributing to Open Source with Elm... forget it...

PureScript contributors are super awesome! They are responsive and they really collaborate!

[srid]

For those that arrive here late, one another option to consider is GHCJS.

Specifically Reflex.

One key advantage here is the ability to share types between the frontend and the backend. Furthermore reflex-platform provides tools the build Android and iOS apps out of the same frontend code base. Everything is in Haskell. This is already being used in production (eg: wrinkle uses it)

[JivanRoquet]

@srid

One key advantage here is the ability to share types between the frontend and the backend

If your Types.hs is shared, yes., which means it has to be a monorepo for front and back. Which means that you're still stuck to GHC 8.6 for the front and the back, while GHC 9.1 is about to become LTS soon. In short, you need to accept that your backend uses a 3-years stale version of GHC if you want to benefit from type sharing.

[srid]

Wow, this issue is nearly 5 years old. Back to this topic, you might be interested in my notes here.

[JivanRoquet]

Very interesting, thanks. The GHCJS devs seem to be all about 8.10 branch as of now, and I agree that more than a year of no update for master is not the best signal.

Have you ever tried Miso, the GHCJS framework? Looks quite well maintained from what I can see. Not sure if it answer your concerns about Obsidian Systems.