Skip to content

Comment on State of the Haskell Ecosystem – February 2016parent

Comments

While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement.

Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D

js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax.

TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.

largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined

I wonder if any research has been done here as to "let the stack grow" and THEN trampoline before it overflows.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.