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.
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 :)
> 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.
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.
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.
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.
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.
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.
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.
> 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).
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.
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?
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.
* 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:
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