Hacker News Reader

Comment by sulam | Hacker News Reader

All the ML inspired languages seem to fall over on compile time. This post is a good example, where it describes design choices driven specifically by compile time, which is not a dimension I usually want interacting with the way I structure my code. I love the rest of the story (full disclosure: I have years of experience with Scala and Swift, which are no better) but until sufficiently advanced compilers arrive these languages are going to continue to be a hard sell for a substantial group of developers.

View on HN

> where it describes design choices driven specifically by compile time

I'd like to point out two things here:

1. There are common library functions that we put in single files. These are imported by a lot of other files. The fact that these incur a large recompile cost is unfortunate and I think it doesn't have to be this way if dependencies were calculated at a more granular level.

2. The far larger implication to compile time becoming exponential is coupling of concerns. This is solely in the developer's responsibility. For a type system that guarantees correctness of code, there is no way around the fact that all affected modules must recompile. eg, if a fundamental law of physics were to change, the whole universe would have to recompute.

So I think for a 'substantial group of developers', the focus should be on helping people to recognise what is coupling and how to design de-coupled systems.

Beyond separate compilation, incremental compilation can go a far way here in minimizing what has to be recompiled on a change. You can even be incremental at tree level for really aggressive change latency reductions (though batch becomes lower because of memoization overhead, not to mention memory consumption concerns).

OCaml has a fast compiler

The strange bit with Elm is that it limits its type system just enough that compile times should be reasonable: The performance pits that Scala has are skirted altogether by Elm. If Elm isn't faster at compilation time, it's because that's not where the focus has been. I might be missing something though, and I'd be happy if Evan corrected me on this one.

As far as Scala goes, Grzegorz Kossakowski has done work trying to get major performance improvements out of Scala type checking, and his numbers look very promising. Barring some Shapeless-style type level computations, Scala could compile quite fast.

Reply on news.ycombinator.com