Hacker News Reader

Comment by christiansakai | Hacker News Reader

I really want to use PureScript, but I wonder why I should use PureScript if I already have TypeScript?

Besides, as far as I know, the PureScript part is only for the business logic, not for the rendering, etc like if you want to use React or Angular or pure DOM manipulation. The backend story goes the same (i.e, PureScript only for business logic).

With the extra tooling required (i.e, spago, bower) it seems pretty pointless to use PureScript these days, what am I missing? Someone please convince me to use PureScript.

View on HN

You want Typescript because you want to write JS with type ascribtions that will catch some errors (but give you a false sense of security in more complex code). You also prefer to use JS idioms and using hundreds of npm packages, so you want the most frictionless integration for that.

You want PureScript because you want the safety of Haskell style functional programming on the frontend, with strict types, effects tracking, category theory, and all.

You want Scala.js because neither of these extremes are appealing to you. You've been burned by Typescript, you're interested in functional programming but don't want to completely give up the good parts of OOP just yet (or ever).

I'm here to sell Scala.js (of course). You can use it with React or with one of Scala.js UI libraries. It's very nice.

Random interesting factoid: the guy behind Scala.js (and lots of other awesome Scala libraries) is actually the son of the prime minister of Singapore. I discovered this when talking to some Singaporeans who were quite surprised to hear the name in the context of programming language libraries. This means that if like his father and grandfather he eventually becomes prime minister, it'll be the first to-Javascript compiler maintained by a head of state.

I do find it interesting. I can't speak for Singapore's rules of succession, but I will nitpick however that Li Haoyi does not maintain the Scala.js compiler, that would be Sebastien and Tobias. He is nevertheless an exceptional, foundation-building creator in the Scala.js ecosystem, and has been at it from the start.

https://github.com/com-lihaoyi

https://github.com/lihaoyi?tab=repositories

https://www.lihaoyi.com/

Thanks for clarifying! I assumed he was the maintainer because he's put a lot of effort into publicising it.

I remember when the PM's wife very leisurely but thoroughly calculated the duration for a missile from NK to reach sg. https://www.facebook.com/permalink.php?story_fbid=8576844644...

So that puts Scala in the same corner as ReasonML and ReScript: FP with OO. Maybe Kotlin(JS) may also join, while that is OO with some FP.

Of all these languages I find Scala the "biggest" language: most syntax to learn, most quirks, least notion of what is idiomatic.

I'm not here to sell Scala, more warning people to stay away from it.

I dunno what's the problem with Scala's syntax, it's pretty standard and uniform.

The language, like any other, does have some quirks, but Scala 3 takes care of many long standing problems (in RC1 already).

It's true that there is no single idiom for Scala code. That's because unlike other languages, it's a true multiparadigm language, and so different people actually do use it differently. It's not a monoculture, but there is a well defined idiom for each style, be it hardcore FP, or Actor based programming, or Java++, or something in between.

Anyway. Ocaml is one of the better alternatives, but it's not without its problems either, both in terms of language and ecosystem.

PureScript isn't just for business logic at all - it has its own UI libraries, React bindings, DOM API bindings, and so on. It is more often used for front-ends than anything else that I've seen.

You only need to use one of spago or bower (spago being the recommended choice now), and that's because npm style dependencies are not suitable for PS.

As for why you'd choose it over TypeScript... well, you'd do so if you want to use a functional language that doesn't allow arbitrary effects and has a sound type system.

I haven't actually checked more on PureScript and about the UI libraries and so, I'll try to dig more.

Halogen is a popular one https://purescript-halogen.github.io/purescript-halogen/

Huh, I would go the other way around:

If you're adding all the complexity that comes with using a language that must first be compiled to ECMAScript anyway, then why would you pick a language that's essentially ECMAScript with fancier clothes?

The build chain complexity tax is already paid. Now you can go for the best language the ecosystem offers. Half-measures seem wasteful.

(This was at least how I reasoned when I went for F#-to-ES.)

> Half-measures seem wasteful.

I would be very very cautious about this line of reasoning. It can work for certain situations, but there are enough tradeoffs and exceptions that I am hesitant to recommend this as a general rule of thumb.

The ability to incrementalize risk (JS code snippets on the web just work, the compilation target is trivial to deduce, runtime characteristics do not change, no need to write wrapper code to consume npm packages, etc) instead of taking a lump sum hit to your novelty budget is valuable. Not always overwhelmingly so, but enough to give me pause.

This is a good counter-argument to my simplistic view. Thanks for bringing it up!

If you considering Purescript then also look at Elm.

Few plusses

- It handles dom manipulation. - Simpler syntax - Elm-UI framework - No extra dependencies

I tried Elm but it is too DSL for me. Its approach also doesn't scale. Too much writing, like Redux.

> I tried Elm but it is too DSL for me.

Fair. And that's what it wants/advertises to be. "Not a general prog lang".

> Its approach also doesn't scale. Too much writing, like Redux.

Not sure what you mean by this. Software that needs to scale do not run in browsers. Elm is just for the FE bit, the UI, the interactive browser stuff. Hence the DSL thing makes sense (to me); though I totally understand one does not like that.

And when it comes to writing: it has very terse syntax. Look at all TodoMVC examples and you find that Elm will use about the least number of characters of any implementation that gives strong typing guarantees.

As far as I've heard, it's crippleware as of v0.19

Reply on news.ycombinator.com