Hacker News Reader

Comment by tel | Hacker News Reader

I feel like you've not seriously used each of them. Ghcjs is very interesting, but also very, very early. The ecosystem is tiny, the compiler produces huge and slow builds, the interop is tricky, the semantics imperfect. It may be a very long time before any of those are resolved, too! Compiling a lazy language to Javascript is no simple trick. Luite deserves all the praise in the world for getting it this far... but there's just a long way to go.

So, in the terms of this article, Ghcjs might be around the same place Scala.js was 2 years ago. In the mean time, Scala.js has taken off in a lot of ways. It's yet to be seen what will happen with Ghcjs.

View on HN

Your hunch is correct, I have not really used either, I'm just generally interested. From a distance, they both appeared to be ambitious and somewhat immature. I'm curious about your comment regarding tricky interop and "imperfect semantics" of ghcjs, could you elaborate? Certainly laziness does make FFI harder, but I wouldn't call that a problem with the semantics.

Laziness doesn't just make FFI harder (although it does do that too) it also makes code generation harder and implies the need for a sophisticated runtime. All of this makes the generated code bigger, slower, and more opaque.

A strict language can just skip all of that so long as it's willing to live within the limitations of the Javascript model. Scala.js does that for the most part and ends up with both nice FFI and a minimal runtime.

I don't see being strict or lazy as being the main source of the size of the deployed code (especially as Ghcjs inherits an excellent strictness analyser from GHC). Scalajs would have to emulate many JVM characteristics and port many JDK classes. Then you have huge core Scala libraries like collections, which are far larger and more complex than the Haskell equivalents. You will have to back up your argument with numbers to convince me. You also haven't elaborated on your comment about "imperfect semantics".

The main difference is that Scala.js people sat down and did all the painstaking work, while Haskell devs spent the time talking how intellectually superior the are and got nothing done.

> Haskell devs spent the time talking how intellectually superior the are and got nothing done.

I could give a recap of Haskell development that's happened while Scala.js has been developed to debunk this silly accusation, but it wouldn't change your mind.

Well, Scala.js went from not existing to rock solid in 3 years. The various Haskell-to-JS efforts existed much longer, but none have the support, completeness and maturity of Scala.js.

That is down to who has the most funding. Javascript itself has even more "support, completeness and maturity" than Scalajs. But obviously that's not the deciding factor.

Scala.js was largely done by a single student on top of his other university duties.

I think it's mostly down to determination. Some things are hard, but need to be done.

Haskell people just seem to give up more easily - see all the half-working projects. Nobody finishes stuff, the next dev just starts his own new project, and abandons it later.

Scala.js handily beats JavaScript in terms of IDE support and tooling

A quick Google suggests Scalajs has had developers paid to work on it (EPFL lab and Lightbend): http://scala-lang.org/blog/2016/03/14/announcing-the-scala-c...

The Haskell community has achieved great things even though most contributions are done in people's spare time. That is determination.

That's nonsense. I think it's great that outside contributions (like allowing the use of the Scala's CI infrastructure) are valued, but the actual commits show a clear picture.

There is no determination in failing to get anything done and doing NIH for a decade.

I'm not really interested in putting in the effort to convince you. This opinion arises from conversation I've had with users of ghcjs, developers of ghcjs, and people very familiar with GHC compilation pipeline details and runtime details.

The last I heard, the primary dev of ghcjs intended to build a new codegen which would alleviate some of the issues here, but that hasn't happened yet to my knowledge.

The comment about imperfect semantics arises from a few weirdnesses around JS interaction with laziness. Perhaps the biggest one I remember is that when calling Haskell from JS you have to be prepared for the idea that results may not be fully evaluated. There wasn't any real mechanism to force and block on the Javascript side and certainly no mechanism to handle it asynchronously (promises wouldn't work unless they decorated inner layers of a data types which would be terrible).

This also plays out on the Haskell side in terms of managing retention strategies.

In a strict language both of these obviously just vanish.

FWIW, this matches my understanding of the situation with Ghcjs, although there's substantial risk that my understanding is dated.

Reply on news.ycombinator.com