Purescript-native can now target Golang | Hacker News Reader

Purescript-native can now target Golang

discourse.purescript.org

171 pointsmaxekman33 comments

Tangential, but some very cool things are happening in Purescript-land, especially when it comes to row types or UI research:

* https://github.com/natefaubion/purescript-variant (open variant types)

* https://github.com/natefaubion/purescript-run (extensible effects implementation based on purescript-variant)

* https://github.com/ajnsit/purescript-concur (time-reifying UI framework, there's also a Haskell and a JS implementation of Concur)

* https://github.com/arthurxavierx/purescript-comonad-ui-todos (comonadic UIs)

* https://github.com/paf31/purescript-purview (incremental lambda calculus UI library, this is mind blowing!)

* https://github.com/paf31/purescript-sdom (declarative diff-less UI library)

There's also [0], a mature UI framework used in production at Slamdata. Lumi [1] are writing their frontend in Purescript.

What I especially like about Purescript is that the community is open to experimentation, while at the same time not being afraid to backtrack when things turn out to be a bad idea, like the row tagged Eff monad. The recent addition of QualifiedDo is a good example of this, which allows you to rebind >>= in the following manner:

  test :: forall m a. I.IxMonad m => m a a String
  test = I.do
    a <- I.pure "test"
    b <- I.pure "test"
    I.pure (a <> b)

Imo, there simply is no better way for a Haskeller to target JS at the moment.

[0] https://github.com/slamdata/purescript-halogen

[1] https://www.lumi.com

I've tried several times to use Purescript to target web browsers. I got frustrated by Bower - it's especially hard to start a new project using tools that say "don't use me, I'm deprecated". There was a huge amount of fairly sloppy javascript boundary code. And - it turns out - I like laziness.I dunno, I wish I could run ghc code efficiently in a web browser. But even though I can't, I much prefer to run ghc code inefficiently in a web browser than run a language intended to facilitate binding to javascript's sloppy semantics.

When I tried using ps-concur or some other ps gui libraries, I didn't feel inclined to keep progressing. When I learnt reflex with ghcjs, I built stuff, and I kept finding new things I wanted to build.

The best way for a Haskell to target browsers at the moment is via ghcjs. Hopefully one day it'll be with a ghc-to-wasm compiler.

I think Bower was just a "good enough" solution when Purescript was initially implemented. Afaik, people are moving away from it in favor of spago [0] or psc-package [1].

JS' semantics are pretty much opaque when staying in Purescript. Of course all bets are off when using the FFI, but then again the same goes for GHCJS.

One major thing in favor of GHCJS is the ability to share code between backend and frontend, but that's not a concern when e.g. the backend is written in another language anyway.

EDIT: Also, Purescript on the backend (targeting node or native code) is slowly becoming a thing as well, as this is what this submission is about :)

[0] https://github.com/spacchetti/spago

[1] https://github.com/purescript/psc-package

> but that's not a concern when e.g. the backend is written in another language anyway.

well, for anyone who's been in this situation, it should be a concern, since it's incredibly easy to get out of sync between backend and frontend (e.g. model, validation, etc.).

Ideally we could all code in preferred-language; target all major platforms using a single/universal UI framework, and call it a day...but reality is messier than that, we're often forced to code apps in multiple languages, multiple UI frameworks (if targeting native iOS + Android, and browser/PWA), and hope it all comes together such that the house of cards stays standing through language/framework/platform upgrades.

I agree, but what I meant is that if you're forced to use a language other than Haskell on the backend, than there's no advantage in choosing GHCJS over Purescript in terms of code sharing.

You don't have to use Bower. I've been writing PureScript for a good while now, and I've never used Bower directly.

https://github.com/spacchetti/spago

This is indeed interesting research. But I think Elm makes more sense if your client-side logic is relatively simple, so that you're basically just defining a view in your frontend code.

Wow, hadn't kept up with purescript at all. It can now compile to JS, Go and C++11 and supports full interop in all 3 cases! That's pretty damn cool.

How's the language itself? I had heard it was a Haskell clone, is that still mostly true? If not, where does it differ and differentiate itself?

It compiles to Erlang too. The language itself is extremely similar to Haskell but with some refinements around some of the legacy baggage Haskell suffers from (string handling for example). Some differentiators include: strict evaluation by default, handling of record types, an extremely modular package policy (nothing is imported by default), and a lack of some things that can potentially make Haskell esoteric at times (template Haskell for example). The community is small but dedicated. Documentation can be very minimal in a lot of cases, so it’s not a beginner friendly language, but once you are up and running, it’s a pretty awesome experience overall.

Also the dev tooling isn't an afterthought and the IDE experience is top notch. (This isn't very different from Haskell nowadays with HIE).

In my experience attempting to learn it you have to be pretty familiar with Haskell since as you mention a lot of stuff isn't well documented outside of types and small blurbs.

It's been a year since I tried and I'm sure a ton has changed since then but I don't expect this to be different for a while. Which isn't necessarily a bad thing, as all new languages have this problem and learning Haskell is very valuable experience for any programmer - just not an easy one.

Basically PureScript isn't something you can jump into like Elm or Typescript or w/e, while being an experienced programmer who knows JS or non-Haskell-y languages, but it's future is very bright if it gets mainstream adoption IMO and I'm following it closely.

And don't forget first class records with row polymorphism!

Interested readers might want to Try PureScript[0] for a quick demonstration.

[0]: http://try.purescript.org

Hum, that sounds pretty neat actually. How does it manage purity without lazyness?

Found some instructions for how to use the Golang backend: https://github.com/andyarvanitis/purescript-native/blob/gola...

PureScript always seemed like a saner, more practical Haskell to me. Is that the case? How useful is it in real world applications these days? I've never really played around with it.

In some sense it's the contrary.. the typeclass hierarchy has a lot of idealism that won't fly in Haskell's comparatively pragmatic Prelude (DivisionRing? Really?)

They even backtracked their version of IO, that used row types to track effects - because it just wasn't worth it.

Can you explain what you mean by "DivisionRing? Really?"?

I see this doc regarding the Eff rows IO change, which must have happened after I last used Purescript https://purescript-resources.readthedocs.io/en/latest/eff-to...

For me personally using something heavyweight and bolted-on like GHCJS for Purescript's typical JS-replacement use-case's seems to be a far worse option. Even if Haskell is more mature and refined as a language. Particularly the real world production examples of GHCJS-backed apps I've seen people post on /r/haskell have all been bloated, slow, non-web standard, and obviously designed by backend programmers not designers/web developers... so I may be biased. Although that stuff has as much to do with community as it does technology.

> Can you explain what you mean by "DivisionRing? Really?"?

My guess is that OP is saying that PureScript’s DivisionRing compared to Haskell’s Fractional is neither practical nor pragmatic.

> For me personally using something heavyweight and bolted-on like GHCJS […]

In my experience the majority of Haskellers agree that GHCJS is not the way to go wrt. web apps.

But I’m not convinced that inventing a new language that’s almost identical to Haskell is the right solution.

I see, thanks for the reply.

But you have to admit there is some utility in designing a language from the ground up to target browsers.

I’ve never understood the OCaml and Haskell people’s obsession with creating half baked JS generators that produce less than great web apps. And I completely get the backend guys desire for a proper language when they are forced by their companies to do web stuff. But that cross platform stuff has repeatedly been an unfulfilled pipe dream. Not only JS to mobile but systems/server languages to web.

I’ve been looking for a proper functional and typed replacement to JS for years and Purescript is the only one I’ve seen that is close to being as good as the Vue/React apps I get paid good money to develop for a living. https://lumi.com is a good example of a modern web app being built by the main PS creator.

I’m hoping one of you smart Haskell people solves this problem before I get old having to use JS.

Is bucklescript half-baked in your opinion? Why?

I think parent referred to Ocsigen, which produced a several Mb js payload for a hello world when i played around with it

Yes exactly, among others such as Miso.

> Purescript is the only one I’ve seen that is close to being as good as the Vue/React apps I get paid good money to develop for a living.

Purescript is a language, are you saying that the language itself allows for creating View/React apps without need of a framework? Or do you mean that there are native (in the ecosystem sense) Purescript UI frameworks that allow one to create View/React apps without depending directly on JS ecosystem to handle the UI?

Wonder how PS compares to OCaml/BuckleScript wrt to generated code size (the latter is absurdly tiny somehow, just incredibly efficient on that front).

> PureScript always seemed like a saner, more practical Haskell to me.

What gave you this impression?

Saner: no language extensions and a bit more explicitness with imports, plus claims of other cleanups.

More practical: claiming smooth interoperability with JS, whose package ecosystem sees more development and whose runtime is widely available.

Are there any websites indexing "underground" languages to indicate their current adoption status ?

From "only the language developers and their friends are working with it, for experimental projects",

to "some fancy startups are using it with good results thanks to its cool new features" ?

I don't mean it as a way to depreciate the work people put onto those projects, but it would certainly help with understanding what one's expectations should be.

If i take OP example : adding a new target to a language that's already heavily used in some startups in production doesn't mean the same thing than if the language is just used for toy projects and experiment. We all know how hard it is to reach production-grade quality (for pretty much anything), and how many good ideas simply collapse on the face of overlooked details from the real world.

When the author mentions that Go’s build system is useful in this scenario, what does he mean? Can Purescript compile to Go with “go build”? Doesn’t make sense to me. I’ll be sure to give this a try!

Presumably it means that Purescript compiles to Go which can then be built with "go build" instead of compiling to C++ and leaving it to the user to figure out how to compile it with their other C++ sources.

Good but I wouldn't give it a try unless I see working code repo which has working REST server along with basic SQL database driver integration.

Test suite integration and project build tips would be nice.

Can someone explain the advantage of using Go as an intermediate language?

Since there's no way to translate Go back to PureScript, I assume the intention isn't to write an application in PureScript, compile it to Go, and edit the resulting Go code.

So is this just a way to utilize the Go compiler to produce binaries from PureScript, or am I missing other use cases?

To use Go libraries, runtimes and deployment tools.

My target use case would be to write the domain logic parts of a business system in PureScript together with a lot of other services where Go makes more sense.

Surprised that Purescript is still a thing, it appears to have died out from all conferences that focus on new tech like StrangeLoop and similar.

Reply on news.ycombinator.com