Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe, but Phil (the author of PureScript) stated that he has no desire to compete with Haskell generally and he rather focus on polishing the JS backend.

There are already a few backends for PureScript[1] (including python!) but most backends went stale as the language progressed, maybe they'll get more love after 1.0?

[1]: https://github.com/purescript/documentation/blob/master/ecos...



It would be nice if they focused on the JavaScript backend a little bit. There's issues like https://github.com/purescript/purescript/issues/2577 that show the serious performance issues the language has with its primary back end.


I have to say that I'm constantly impressed with the level and tone of discussion in purescript development. That thread is a pretty good example. It looks like your wish is being fulfilled :-)


An active C++ backend. I'm now more and more interested.

I'm not suggesting competing with Haskell, but Haskell doesn't really target industry, never has and never will.

PureScript is very industry focused. With a solid Erlang and JavaScript backend, it gives you quite a nice single language for a lot of industry use cases, and with a possible C++ backend, might even work out for more cases.

Haskell pushes the envelope of typed FP even further, and adds laziness to it all. But I think there's room for something like PureScript to bridge the gap. If the Polish is there, and the tooling, and a strong commitment to stability, I can see a bright future.


> Haskell doesn't really target industry, never has and never will.

Why do you say that?


It's not that Haskell can't be used by industry, it's just that the language has mostly been used by enthusiasts and academia (that's not a bad thing). No big companies have really committed to making Haskell industry focused. Facebook has dabbled in it and even made some improvements to the GHC compiler but I don't think they are replacing swaths of their tech with Haskell.

I agree with the "never has" part of the statement but a little skeptical on the "never will" cause we can't really predict that. I feel like the language itself has been picking up popularity in recent years so who knows.


We can't predict that, and maybe it will one day, but I think that's unlikely. Academics will continue to want and extend Haskell more and more, and it'll enter into a conflict I believe between pushing the typed lambda programming paradigm further into research territory and having a slow and stable industry base that favors backwards compatibility, stability and performance.

There might be a way to have both sustainably, but I'm not sure why we'd want that.

I really wouldn't mind seeing Haskell continue to innovate and be a trial for innovative features, and have another slower Haskell like language which slowly and carefully brings back those features into itself once they've been proven mature enough.


> having a slow and stable industry base that favors backwards compatibility, stability and performance

I feel as if GHC addresses backwards compatibility and stability fairly well with new language features being gated by language pragmas. [1]

I don't write much Haskell in production, and what I do write isn't very performance intensive, but GHC's been pretty impressive vs. other compilers with languages at a similar level of abstraction.

[1] Foldable/Traversable in Prelude was a relatively large breaking change, and it was handled in a way that minimized the impact to existing code while still advancing the language.


> Facebook has dabbled in it and even made some improvements to the GHC compiler but I don't think they are replacing swaths of their tech with Haskell.

Their anti-spam and messaging evaluation system, for the whole system, is written in Haskell.


> Haskell doesn't really target industry, never has and never will.

There are contributors to ghc who add features or fix bugs with "industry use" in mind.

So your statement in its current form is a bit confusing to me.

Can you elaborate?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: