The reason for why it hasn't been a problem for us is because we've been making heavy usage of SBT's support for sub-projects. Scala makes it easier than other languages to decouple components, so after a while you begin to spot possible sub-projects all over the place.
The project I'm working on right now is about 15kloc, but it's split in 3 sub-projects. Coupled with incremental (and continuous) compilation, this compilation speed issue hasn't been a problem for me.
Also, if you look around, many open-source projects built with Scala follow the same technique. It's quite sane too.
Out of curiosity, how much of a problem is it? Is incremental compilation noticeably slow or is it just the full compile?
Re:Scala 2.10 now available
by yummyfajitas on Friday January 04, 2013 @03:43PM
(#5009761)
It's friction in the development process.
Incremental compilation suffers from the fragile base class problem. In a well structured app with proper encapsulation and rigid (and type annotated) interfaces, it helps a lot.
Re:Scala 2.10 now available
by felipehummel on Friday January 04, 2013 @07:17PM
(#5010760)
How many times you do full recompile during a day? I'm curious because in my workflow I rarely do full recompile.
Re:Scala 2.10 now available
by yummyfajitas on Friday January 04, 2013 @09:46PM
(#5011242)
If your project isn't properly encapsulated, incremental recompilation will often come close to a full recompile, or at least recompilation of a big chunk of code.
For example, if you delete AbstractFooBase.unusedMethod, sbt will recompile every file everywhere that references a concrete Foo instance.
(In principle it should only need to recompile files which reference unusedMethod, but it's not that smart yet.)
Admittedly, we do make heavy use of the type system.