4 ms·

> Now, you have a basic idea of the challenges that fast compilation in a modern programming language poses. Note that some languages deliberately chose to make

by etse 6y ago

> Now, you have a basic idea of the challenges that fast compilation in a modern programming language poses. Note that some languages deliberately chose to make their compilers not that smart to avoid having to do all this. I’m not knowledgeable enough to read between the lines, but is this a veiled reference to Go? If so, what about Go is intentionally not smart, and why? (Or language X)

mac01021 6y ago
The first sentence if the article: "Compiling a lot of code fast is a hard problem, especially when the compiler has to perform complex analyses such as overload resolution and type inference with generics." The go language doesn't have either if those things, so the compiler has less work to do per line of code. But it seems like you knew that? You're the one that brought up Go.
antimetropic 6y ago
There may be other languages that have taken a similar approach—I’m not up to speed on that—but simplifying elements of the language design to enable fast compilation was definitely a conscious design choice for Go. See Rob Pike’s 2012 talk “Go at Google: Language Design in the Service of Software Engineering” video + slides: https://www.infoq.com/presentations/Go-Google/ https://www.infoq.com/presentations/Go-Google/ transcript: https://talks.golang.org/2012/splash.article#TOC_5 https://talks.golang.org/2012/splash.article#TOC_5. Some of the things it calls out: - unused dependencies are a compile-time error - dependency graph has no cycles - importing a package only looks at object files, not source files, so template/macro stuff is generally out - declaration order is reverse from that of C so that parsing code is faster and easier
didibus 6y ago
I felt maybe it was more taking a stab at Java? Since it was saying it wants type safety but without making the code ugly with type annotations everywhere.
brabel 6y ago
I don't think they are referring to Go, a lot of languages avoid adding features that inevitably would add to compile times... Java for example (which I think is more likely what the author had in mind)... it requires you to end every statement with a semi-colon. Kotlin removes that restriction, but that costs compilation time (Kotlin seems to use a heuristic that if it's possible to terminate an expression when a new-line is reached without it being a compile error, then it does it... in some cases, a new-line is required even if it "looks like" it shouldn't be needed, e.g. `val func = {} val x = 0` doesn't compile). There are many features like this in Kotlin, and it shows as the Kotlin compiler is nowhere near the speed of the Java compiler if you don't use a freaking compiler daemon. I had a test suite that used `StringSpec` to make tests prettier to write, but after a few hundreds of those, my Kotlin tests started taking visibly longer to compile than the Java source code (which was much larger)! So I had to re-write the tests to use plain Kotlin functions instead. All languages I know that have "advanced features" have notably slow compilers: Rust, Scala, Haskell. I would be happy to know if there's any counter-examples (I might almost include Kotlin as a counter-example, actually, as it's not so bad if you let it run the Gradle daemon to use the techniques mentioned in the article - but that feels a little bit like cheating as you're getting fast by just avoiding compiling everything). So while I think the trade-off is worth it most of the time, it's something to be aware of and consider in your decision when choosing a language.
- dwohnitmok 6y ago
  Depends what you mean by advanced features, but OCaml has very fast compile times (usually faster than Go IIRC).
  - brabel 6y ago
    That would be truly impressive, given how OCaml has global type inference IIRC!
    - wilsonthewhale 6y ago
      OCaml is usually compiled by module, and module-module interfaces mostly all have explicitly declared types (in the .mli), so it's usually not very global, just within the module.
slaymaker1907 6y ago
One of the things go does is generate bad code [1]. [1]: https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-be-smarter/ https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-b...

by etse 6y ago

mac01021 6y ago

The first sentence if the article: "Compiling a lot of code fast is a hard problem, especially when the compiler has to perform complex analyses such as overload resolution and type inference with generics." The go language doesn't have either if those things, so the compiler has less work to do per line of code. But it seems like you knew that? You're the one that brought up Go.

antimetropic 6y ago

There may be other languages that have taken a similar approach—I’m not up to speed on that—but simplifying elements of the language design to enable fast compilation was definitely a conscious design choice for Go. See Rob Pike’s 2012 talk “Go at Google: Language Design in the Service of Software Engineering” video + slides: https://www.infoq.com/presentations/Go-Google/ https://www.infoq.com/presentations/Go-Google/ transcript: https://talks.golang.org/2012/splash.article#TOC_5 https://talks.golang.org/2012/splash.article#TOC_5. Some of the things it calls out: - unused dependencies are a compile-time error - dependency graph has no cycles - importing a package only looks at object files, not source files, so template/macro stuff is generally out - declaration order is reverse from that of C so that parsing code is faster and easier

didibus 6y ago

I felt maybe it was more taking a stab at Java? Since it was saying it wants type safety but without making the code ugly with type annotations everywhere.

brabel 6y ago

I don't think they are referring to Go, a lot of languages avoid adding features that inevitably would add to compile times... Java for example (which I think is more likely what the author had in mind)... it requires you to end every statement with a semi-colon. Kotlin removes that restriction, but that costs compilation time (Kotlin seems to use a heuristic that if it's possible to terminate an expression when a new-line is reached without it being a compile error, then it does it... in some cases, a new-line is required even if it "looks like" it shouldn't be needed, e.g. `val func = {} val x = 0` doesn't compile). There are many features like this in Kotlin, and it shows as the Kotlin compiler is nowhere near the speed of the Java compiler if you don't use a freaking compiler daemon. I had a test suite that used `StringSpec` to make tests prettier to write, but after a few hundreds of those, my Kotlin tests started taking visibly longer to compile than the Java source code (which was much larger)! So I had to re-write the tests to use plain Kotlin functions instead. All languages I know that have "advanced features" have notably slow compilers: Rust, Scala, Haskell. I would be happy to know if there's any counter-examples (I might almost include Kotlin as a counter-example, actually, as it's not so bad if you let it run the Gradle daemon to use the techniques mentioned in the article - but that feels a little bit like cheating as you're getting fast by just avoiding compiling everything). So while I think the trade-off is worth it most of the time, it's something to be aware of and consider in your decision when choosing a language.

dwohnitmok 6y ago
Depends what you mean by advanced features, but OCaml has very fast compile times (usually faster than Go IIRC).
- brabel 6y ago
  That would be truly impressive, given how OCaml has global type inference IIRC!
  - wilsonthewhale 6y ago
    OCaml is usually compiled by module, and module-module interfaces mostly all have explicitly declared types (in the .mli), so it's usually not very global, just within the module.

slaymaker1907 6y ago

One of the things go does is generate bad code [1]. [1]: https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-be-smarter/ https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-b...