Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dark Secrets of Fast Compilation for Kotlin

blog.jetbrains.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: The Dark Secrets of Fast Compilation for Kotlin

#11

Post by brabel »

dwohnitmok wrote: post #10
brabel wrote: post #7

Earlier quoted context omitted.

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 ne…

Depends what you mean by advanced features, but OCaml has very fast compile times (usually faster than Go IIRC).

That would be truly impressive, given how OCaml has global type inference IIRC!

Re: The Dark Secrets of Fast Compilation for Kotlin

#12

Post by wilsonthewhale »

brabel wrote: post #11
dwohnitmok wrote: post #10

Earlier quoted context omitted.

Depends what you mean by advanced features, but OCaml has very fast compile times (usually faster than Go IIRC).

That would be truly impressive, given how OCaml has global type inference IIRC!

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.

Re: The Dark Secrets of Fast Compilation for Kotlin

#13

Post by slaymaker1907 »

etse wrote: post #2

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

One of the things go does is generate bad code [1].

[1]: https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-b...

Re: The Dark Secrets of Fast Compilation for Kotlin

#14

Post by dwohnitmok »

wilsonthewhale wrote: post #12
brabel wrote: post #11

Earlier quoted context omitted.

That would be truly impressive, given how OCaml has global type inference IIRC!

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.

Not many language have cross-module type inference. For example I'm pretty sure Haskell does not have cross-module type inference (you need `.hs-boot` files to help it along if you want cyclic modules for example). So in that sense OCaml's type inference is no weaker than other languages with global type inference.

And in fact type inference is generally not what slows down compilation. It is often barely any more expensive than type checking (and indeed for languages with global type inference a viable way to implement type checking is to run type inference and then compare the generated type signature with the annotated signature). This is especially true for OCaml which requires definitions to be in order or otherwise explicitly marked as recursive (so the type inferencing algorithm can immediately add a term's inferred type to the current typing judgment as a known type). What's slow is usually recursive implicit definitions and optimizations. This means typeclass-heavy signatures for Haskell and frequent use of recursive implicits in Scala.

Re: The Dark Secrets of Fast Compilation for Kotlin

#15

Post by ysleepy »

dilap wrote: post #8
meisel wrote: post #6

Seems less “dark secrets”, more “incremental compilation 101”

It's a dark secret if you're used to maven and java...

Maven is incremental per default. Also java compilation is much faster than kotlin, so it is less of a problem.

Furthermore, IntelliJ (as much as I love it) has a terrible live compilation story compared to eclipse. Eclipse recompiles affected project files while you type and propagates errors live. Harp on java where it's at least factual, (crufty stdlib, missing uints, type erasure..). Java is miles ahead what tooling and maturity of the ecosystem is concerned.

Re: The Dark Secrets of Fast Compilation for Kotlin

#16

Post by dilap »

ysleepy wrote: post #15
dilap wrote: post #8

Earlier quoted context omitted.

It's a dark secret if you're used to maven and java...

Maven is incremental per default. Also java compilation is much faster than kotlin, so it is less of a problem. Furthermore, IntelliJ (as much as I love it) has a terrible live compilation story compared to eclipse. Eclipse recompiles affected project files while you type and propagates errors live. Harp on java where it's at least factual, (crufty stdlib, missing uints, type erasure..). Java is miles ahead what tool…

Is it? Maybe our company is doing something stupid then.

I'm not mainly a Java person, but I do sometimes pitch in here and there. We're using maven, and it's definitely not doing incremental compilation. I mentioned this was crazy to the Java guys and they said it was normal for maven...

(They're also in an IDE most of the time, so maybe they don't care so much.)

Re: The Dark Secrets of Fast Compilation for Kotlin

#17

Post by ysleepy »

dilap wrote: post #16
ysleepy wrote: post #15

Earlier quoted context omitted.

Maven is incremental per default. Also java compilation is much faster than kotlin, so it is less of a problem. Furthermore, IntelliJ (as much as I love it) has a terrible live compilation story compared to eclipse. Eclipse recompiles affected project files while you type and propagates errors live. Harp on java where it's at least factual, (crufty stdlib, missing uints, type erasure..). Java is miles ahead what tool…

Is it? Maybe our company is doing something stupid then. I'm not mainly a Java person, but I do sometimes pitch in here and there. We're using maven, and it's definitely not doing incremental compilation. I mentioned this was crazy to the Java guys and they said it was normal for maven... (They're also in an IDE most of the time, so maybe they don't care so much.)

They probably invoke maven with "mvn clean package" which does a fresh complete build, but only for deploying it.

Re: The Dark Secrets of Fast Compilation for Kotlin

#18

Post by dilap »

ysleepy wrote: post #17
dilap wrote: post #16

Earlier quoted context omitted.

Is it? Maybe our company is doing something stupid then. I'm not mainly a Java person, but I do sometimes pitch in here and there. We're using maven, and it's definitely not doing incremental compilation. I mentioned this was crazy to the Java guys and they said it was normal for maven... (They're also in an IDE most of the time, so maybe they don't care so much.)

They probably invoke maven with "mvn clean package" which does a fresh complete build, but only for deploying it.

I'm running "mvn install -DskipTests" w/ no files changed. It takes about 22 seconds and I see messages like

> Changes detected - recompiling the module!

> [INFO] Compiling 734 source files...

Perhaps we're doing something strange or dumb or somehow don't have incremental compilation turned on...

Re: The Dark Secrets of Fast Compilation for Kotlin

#19

Post by ptx »

dilap wrote: post #18
ysleepy wrote: post #17

Earlier quoted context omitted.

They probably invoke maven with "mvn clean package" which does a fresh complete build, but only for deploying it.

I'm running "mvn install -DskipTests" w/ no files changed. It takes about 22 seconds and I see messages like > Changes detected - recompiling the module! > [INFO] Compiling 734 source files... Perhaps we're doing something strange or dumb or somehow don't have incremental compilation turned on...

It seems[1] there's a flag called useIncrementalCompilation which is indeed enabled by default but doesn't actually cause any incremental compilation to happen.

Setting the flag to false causes it to compile only changed files, but this will give incorrect results, for the reasons described in the Kotlin blog post.

[1] https://stackoverflow.com/a/49700942

Post reply on HN