4 ms·

How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid

How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? I'm not really a fan of Go but waiting for the compiler can be a pretty significant productivity killer on larger projects. Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming language design.

pcwalton 12y ago
> How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? The vast majority of compile time for optimized builds (80%-90%) is spent in code generation and optimization in LLVM. For unoptimized builds, most of the compile time is spent in the typechecker doing type unifications for method lookup. With some optimizations to quickly reject method candidates I suspect this can be greatly improved. Incremental compilation for the fast turnaround is being worked on and there has been significant progress, to address comex' complaint. > Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming language design. Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.)
- pjmlp 12y ago
  > Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.) You should compare with gccgo, though.
pjmlp 12y ago
Rust compilation times can still be made faster. Generally I think many people complain too much for what takes a few seconds. C++ builds are measured in hours, usually require distributed build systems, clever use of forward declarations and cutting class private declarations into static code or PImpl classes to bring it down to something manageable.
- steveklabnik 12y ago
  While I agree with you, I'll also say that the difference between a second or two and instant is _huge_. The Ruby world has been talking about how to get unit tests runs down for the past few years for this reason. Sub-second test suite runs are _amazing_.
  - pjmlp 12y ago
    I am a huge sponsor of agile, but in the enterprise world I work on, strong type checking wins over unit tests. It is a lost battle trying to make enterprise guys to write a single line of unit tests.
    - steveklabnik 12y ago
      Ruby has strong type checking. ;) Static typing vs. unit tests is a false dichotomy.
      - pjmlp 12y ago
        > Static typing vs. unit tests is a false dichotomy. Not at the enterprise. In what is now almost 30 years of dealing with computer systems. I only had the luck to work at one single company that took unit tests seriously. All the other companies, the guys just write tests if a manager imposes them (usually only if the customer makes it a condition of payment), or they are somehow related to their performance evaluation. Otherwise, the best you can get are integration tests at around one month before delivery date. Ah, and agile in the enterprise is a synonym for a 3 week long mini-waterfall project.

pcwalton 12y ago

> How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? The vast majority of compile time for optimized builds (80%-90%) is spent in code generation and optimization in LLVM. For unoptimized builds, most of the compile time is spent in the typechecker doing type unifications for method lookup. With some optimizations to quickly reject method candidates I suspect this can be greatly improved. Incremental compilation for the fast turnaround is being worked on and there has been significant progress, to address comex' complaint. > Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming language design. Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.)

pjmlp 12y ago
> Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.) You should compare with gccgo, though.

pjmlp 12y ago

Rust compilation times can still be made faster. Generally I think many people complain too much for what takes a few seconds. C++ builds are measured in hours, usually require distributed build systems, clever use of forward declarations and cutting class private declarations into static code or PImpl classes to bring it down to something manageable.

steveklabnik 12y ago
While I agree with you, I'll also say that the difference between a second or two and instant is _huge_. The Ruby world has been talking about how to get unit tests runs down for the past few years for this reason. Sub-second test suite runs are _amazing_.
- pjmlp 12y ago
  I am a huge sponsor of agile, but in the enterprise world I work on, strong type checking wins over unit tests. It is a lost battle trying to make enterprise guys to write a single line of unit tests.
  - steveklabnik 12y ago
    Ruby has strong type checking. ;) Static typing vs. unit tests is a false dichotomy.
    - pjmlp 12y ago
      > Static typing vs. unit tests is a false dichotomy. Not at the enterprise. In what is now almost 30 years of dealing with computer systems. I only had the luck to work at one single company that took unit tests seriously. All the other companies, the guys just write tests if a manager imposes them (usually only if the customer makes it a condition of payment), or they are somehow related to their performance evaluation. Otherwise, the best you can get are integration tests at around one month before delivery date. Ah, and agile in the enterprise is a synonym for a 3 week long mini-waterfall project.