State of the Haskell Ecosystem – February 2016

Re:State of the Haskell Ecosystem – February 2016 by kyllo on Sunday February 21, 2016 @04:46PM (#11146732)

Can someone explain to me why Haskell will ever be viable as a fullstack language?

It already is. If you are talking about a full stack web application, there are several fully featured production quality frameworks, Yesod being the most popular.

What are the negatives to you? Long compile times? Monadic IO? Memory leaks from lazy eval?

[ Parent | on HN ]

Re:State of the Haskell Ecosystem – February 2016 by lvh on Sunday February 21, 2016 @05:19PM (#11146898)

I'm guessing the poster included being able to do front-end work in Haskell. elm and purescript might be plausible front-end languages, but ghcjs isn't really there yet.

[ Parent | on HN ]

Re:State of the Haskell Ecosystem – February 2016 by kyllo on Sunday February 21, 2016 @06:59PM (#11147357)

Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.

[ Parent | on HN ]

Re:State of the Haskell Ecosystem – February 2016 by chadaustin on Sunday February 21, 2016 @11:47PM (#11148504)

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.

[ Parent | on HN ]

Re:State of the Haskell Ecosystem – February 2016 by 15155 on Friday February 26, 2016 @08:30PM (#11185601)

> 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.

[ Parent | on HN ]