Language Highlights

Meetups
#1

Continuation from yesterday’s discussion:

What are some concrete examples of where PureScript shines compared to other languages?

This would be nice to document for folks considering learning PS who do not have a background in Haskell.

A comparison to TypeScript would be really nice. Here’s what I’ve come up with so far:

  • The type system is unsound. This is intentional for compatibility with existing JS. Note that mutability plays a role in breaking the example in the previous link. Lots more type system issues can be found by searching the ByDesign and DesignLimitation labels.
  • Discriminated Unions are the equivalent to ADTs. There’s a lot more boilerplate required to create these and pattern match on them. See this Reducer Example.
  • Libraries like lodash, ramda, and fp-ts provide more FP capabilities, but more boilerplate is required, and these often fail to type check.
  • If an untyped variable cannot be inferred, it defaults to the any type. This can be caught with the --noImplicitAny flag, and you can weed out the rest of them with no-explicit-any, so I wouldn’t consider this a real issue, but figured I should cover it since it came up in yesterday’s meeting.

The trade-offs compared to Elm are pretty straightforward, although might not be as obvious to users who have only known Elm. Here’s my take:

  • Fewer abstractions
  • Tedious JSON encoding/decoding
  • No components
  • Restrictive JS FFI
  • No escape hatches

A great way to demonstrate these abstraction benefits would be to start with RealWorld Elm, port it to a PS TEA framework, then refactor.

I think it’s also important to acknowledge the negative trade-offs with selecting PS over TS or Elm:

  • Learning curve
  • Error messages (especially compared to Elm, but understandable due to abstractions).
  • Performance
  • Ecosystem still being developed
  • Small community
  • Lots of sleeve rolling required

But the good news is that a lot of the above negatives can be improved, while TS will never have a sound type system, and it’s unknown whether Elm will ever allow more abstraction in its type system.

Maybe these comparisons are more fitting for a blog post, but I think we could assemble a more comprehensive set of examples as a community effort.

13 Likes
#2

Here’s a docs issue to track the creation of a very matter-of-fact comparison.
Feel free to lend any insights you have for the languages listed, or if you’d like to see other languages added.

1 Like
#3

I wasn’t at the meetup, so sorry if this is just restating the obvious. When comparing PS to TS I really think the purity of PS as a language is its strongest selling point. I know for me, I was specifically looking for a pure, compile-to-js language and everything else was just icing on the cake. If you’re talking to a TS developer, I think you have to start with the value of purity in a language, and then once they’re convinced, PS is the natural choice. If they’re not interested in purity, it seems unlikely to me that anyone would be convinced to overcome the learning curve and smaller ecosystem just for reduced boilerplate.

Now the sound type system is big deal, though I suspect that if you just want TS but with a sound type system, that’s ReasonML’s corner of the market.

Again, I wasn’t at the meetup, so sorry if these comments are unhelpful in any way. I’m just trying to provide my perspective on what makes PS really stand out as an awesome language!

(FWIW, I have very little Haskell experience. I came mostly from F#, where I’m always fighting the ecosystem to try and build in purity after the fact, which may very well be coloring my viewpoint here.)

3 Likes