5 ms·

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

danielscrubs 6y ago
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?
- thepratt 6y ago
  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.
lmm 6y ago
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.
- gridlockd 6y ago
  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.
  - lmm 6y ago
    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.
  - kccqzy 6y ago
    I use emacs flycheck and the compiler is invoked in the way that doesn't generate object code. It just stops after type checking.
- millimeterman 6y ago
  While true, this isn't a free get out of jail card whenever someone brings up slow compilation. OCaml's compiler is blazing fast.
logicchains 6y ago
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.
- hopia 6y ago
  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.
johnday 6y ago
> 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.
- brazzy 6y ago
  > 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...
  - johnday 6y ago
    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.
hopia 6y ago
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.
whateveracct 6y ago
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.

danielscrubs 6y ago

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?

thepratt 6y ago
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.

lmm 6y ago

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.

gridlockd 6y ago
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.
- lmm 6y ago
  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.
- kccqzy 6y ago
  I use emacs flycheck and the compiler is invoked in the way that doesn't generate object code. It just stops after type checking.
millimeterman 6y ago
While true, this isn't a free get out of jail card whenever someone brings up slow compilation. OCaml's compiler is blazing fast.

logicchains 6y ago

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.

hopia 6y ago
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.

johnday 6y ago

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

brazzy 6y ago
> 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...
- johnday 6y ago
  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.

hopia 6y ago

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.

whateveracct 6y ago

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.