[nickbauman]

Often I do because that's what CI does. This is pretty normal.

But the point is having a different view of what compilation means in the developer's workflow as a language designer. Having the engineer have to think about how to organize the code for the compiler is bad design unless that organization is built into the compiler. The compiler should reject programs that are not organized for optimal compilation. And the organization required at least does not impede understanding of the code (best if it improves it). This is Go's design imprimatur and it's critically important to the success of Go.

FWIW, I see large Java projects compile small changes take minutes to compile, even using hot-reload tools.

Figwheel in Clojure is not like this, however: they're doing something right there.

[nine_k]

However you frame it, compile times are going to be longer the more static guarantees you need to check, and the longer the more dependencies a particular code change affects.

Making your code low-coupling if equally beneficial for the compiler and for the human to reason about the code. Hence modularization, limiting the visibility of parts, etc.

OTOH there are situations when you have to have a common interface which is used across the board. Imagine Java's `List` or `CharSequence`. If you touch it, you have to recompile all the innumerable uses of it. So the more pervasive the dependency is, the smaller and simpler and more fine-grained it should be. Java's `List` does not do a hugely good job in the compactness department; it's pretty stable, though. You want the same trait from your most foundational interfaces.