Hacker News Reader

Comment by gridlockd | Hacker News Reader

The compilation time is the dealbreaker for me right there. If your language is slow to compile, it cannot be that good.

View on HN

If the compiler finds problems that you'd otherwise need a test suite to catch, then as long as the compiler is faster than that test suite you still come out ahead.

If the compiler is slow, I feel unproductive. I need to try out things quickly, I need to iterate. The bugs don't matter at this stage.

You may not need a full compile for that though. Some combination of incremental compilation, non-optimising compiles, or a presentation compiler / typechecker only can be enough to iterate with.

I use emacs flycheck and the compiler is invoked in the way that doesn't generate object code. It just stops after type checking.

While true, this isn't a free get out of jail card whenever someone brings up slow compilation. OCaml's compiler is blazing fast.

Compilation time generally isn't a problem if you work from the REPL (it's super-quick to reload the REPL after changing a file). The only time you pay for a full compile is for release.

Yep, it's the dependencies that take long to compile. Once you've done that already compiling your own source code is a lot faster, probably somewhat comparable to other compiled languages.

I'd say it is at least twice as fast as Scala, and faster than Swift in compilation time.

Any besides OP that experienced slow Haskell compilations?

When Template Haskell or multiple packages join the fray, compilation times can get quite high, quite quickly. This is more an experience with stack, as there are means for incremental caching to avoid full rebuilds when a top-level change is made - nix-build and bazel being a few.

It doesn't help that sometimes stack can't tell if it should rebuild TH or not - a long standing bug.

Incremental compiles in ghci are as fast or faster than my average incremental Go build turnaround. Once you include tests (which you need to run much more in Go than Haskell IME), Haskell begins to win even.

> If your language is slow to compile, it cannot be that good.

I know compilation times are a problem, but this seems untrue. Compile times are a problem of the compiler and not the language. GHC is slow because of how much it is doing behind the scenes. Other, more streamlined compilers may be faster.

> Compile times are a problem of the compiler and not the language.

This is definitely untrue. Language design has a huge effect on how easy (or even possible) it is to write a compiler that scales well.

You can quite easily design a language where compilation is NP-complete...

In my comment (which you responded to) I am using the definite article. "The" language in this case is Haskell, and "the" compiler is GHC.

The inference rules and complexities of Haskell as defined in the 2010 report are minimal and as a result, a fast compiler could theoretically exist for Haskell. Speed is not a primary concern for GHC devs, though.

Surprisingly, this hasn't hurt me as much as I expected it would. Yes, the compilation times are slow but for the most part you have the type checker guide you while developing.

Slow compilations are very annoying for tests though.

Reply on news.ycombinator.com