Hacker News Reader

Comment by jeremyjh | Hacker News Reader

This is ridiculously optimistic. Perhaps many toy programs can be easily converted, but real programs that use libraries other than base will not be so easy to migrate.

I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.

Frege doesn't implement all the language extensions (very commonly used ones, such as MultiParamTypeclasses, are not supported), it doesn't share a build tool. It would be a great deal of work to port any non-trivial program.

View on HN

True, this "ecosystem" is often overlooked.

The goal of the Frege developers is to achieve full Haskell 2010 compatibility by the end of this year. However, that still doesn't mean you can port all code easily.

What it does mean is that you can use your Haskell skills in projects that are for some reason restricted to the JVM.

> I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.

As someone who's standing on the precipice of GHCJS, Haste and PureScript, I'm very curious to hear about your Haste experiences in this regard.

(I've been using PureScript in my side-projects for a bit. For the sake of completeness of this list, I've tried Elm and am not interested.)

I really want to like Haste. It supports nearly all features of GHC, it works with Cabal, it produces small output that can be understood/debugged. Its runtime is only 500 lines of clean javascript. I was able to build a toy app that shared code between client and server and let me use my existing tools to work on it (Hdevtools et al.). For awhile a nice react library was in development for it.

But... its lack of support for TemplateHaskell and native code means that a lot of firewalls/shims are required to share code with likely server programs. There is no support for common library types such as Text and Aeson types - ghcjs has shims for those that build without native dependencies. react-haskell library switched to ghcjs because the Haste ecosystem/development community is non-existent. And I would probably not build a serious project with Haste for the same reason.

ghcjs is nice but...it is too big in so many ways. The runtime footprint for real programs is very large. The complexity of it seems high and it still only has a single dedicated developer. I've heard its performance demands are high - it doesn't seem like something you'd want to run on a phone. It feels too risky to me - Purescript or Typescript is probably what I would go with for a serious project.

Reply on news.ycombinator.com