Admittedly, the largest Scala code base I've worked on was ~200K LOC size which is pretty small. But even that under a full compile/test cycle we were talking minutes in the worst case, dominated by test time. Incremental compile/test cycles were measured in 10s of seconds.

What do you mean when you say "awful" and how does that compare to your test cycles?

It's too easy in scala to create a giant mudball codebase where every file depends on half the project. Managing the compile graph is almost impossible when you have 20 hackers on the same codebase.

Sometimes I wish that scala had some compiler-flag that signals these problems, maybe a restricted mode or something with annotations.

Without significant use of sub projects (i.e. a highly modular and well thought out application structure), you're basically screwed on the compilation front. It's just absolute night and day the difference, compilation hit is reduced by orders of magnitude and development becomes enjoyable.

Will still be a compilation hit for very large projects, but less than with an everything depends on the kitchen sink approach, been through that pain point ;-)

My biggest gripe these days is with the presentation compiler in Eclipse, that can get pretty laggy when working with heavily inferred code, your own, or a 3rd party lib like Shapeless, Scalaz, etc. Not sure if IntelliJ is much better in this area, would be surprised, inference is costly.

Having spent a fair bit of time working in large projects in dynamic languages I think compile times are completely overrated as an issue. Much more important is build times. That is compile, test, package loops. I hardly ever compile in isolation. I am usually running tests, doing code generation, building artifacts as well as compiling. As soon as this is true, compilation times tend to be dwarfed by the rest of the process. Thus my point about compile times being low on my priority list (though I won't defend them).

For instance, lots of people mention Go compile times during discussions such as this and I find that argument non-compelling for the simple reason that on small projects the difference is imperceptible and on large projects the other factors I mention dwarf compile times in either case.

I will say thanks for the concrete time period definition though. 5-10 second turn around seems like a trivial time to argue about to me. If I have to look up from my editor for 1 second it might as well be 30. Anything more than 30 is context switch time. I haven't had to deal with incremental build/test loops longer than 30 seconds in a long time and Scala certainly doesn't require them. Again, I'm perfectly willing to concede this could be a generational difference as I've worked on projects that had compile times measured in hours and (automated) test cycles measured in days.