
Purescript-native can now target Golang - maxekman
https://discourse.purescript.org/t/purescript-native-can-now-target-golang/878
======
pka
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](https://github.com/natefaubion/purescript-variant) (open variant types)

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

* [https://github.com/ajnsit/purescript-concur](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](https://github.com/arthurxavierx/purescript-comonad-ui-todos) (comonadic UIs)

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

* [https://github.com/paf31/purescript-sdom](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](https://github.com/slamdata/purescript-halogen)

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

~~~
casmclas
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.

~~~
pka
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](https://github.com/spacchetti/spago)

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

~~~
virtualwhys
> 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.

~~~
pka
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.

------
didibus
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?

~~~
tmountain
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.

~~~
dmix
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.

------
maxekman
Found some instructions for how to use the Golang backend:
[https://github.com/andyarvanitis/purescript-
native/blob/gola...](https://github.com/andyarvanitis/purescript-
native/blob/golang/README-go.md)

------
rattray
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.

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

What gave you this impression?

~~~
rattray
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.

------
bsaul
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.

------
haolez
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!

~~~
weberc2
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.

------
truth_seeker
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.

------
runeks
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?

~~~
maxekman
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.

------
pjmlp
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.

