3 ms·
We only run into big compilation speed problems when we have the following: 1) Code that is lumped into one gigantic JAR instead of being broken down into seve
by wheaties 14y ago
We only run into big compilation speed problems when we have the following:
1) Code that is lumped into one gigantic JAR instead of being broken down into several different libraries that can be compiled faster.
2) Code that forces the compiler to "solve" many problems in the type system, such as recursion and many other powerful type level constraints.
The first isn't a problem with the compiler, it's a problem with how you're laying out your code. Luckily we don't have this problem.
The second is a problem if you've decided to use a lot of type level programming all over the place. I can't say if this is really a "problem" or not because it depends on your use case.
- seunosewa 14y agoScala's "customers" (coders) don't really care about why compilation speed is slow. They just want it to be fast. Compiling Scala is definitely slower than compiling Java. If it can be fixed, it should be fixed. If not, that may be one more reason why Scala won't be the next Java.
- jakubholynet 14y agoSorry but to me this hears similarly too "coders do not care about why runtime speed is slow, they just want it fast". You cannot get gut runtime performance without understanding the performance constraints of data structures and algorithms you use, Similarly, when using Scala, you must be aware of the performance cost - in compilation time - of the various features and act accordingly. So yes, what can be fixed should be fixed - but I am happy with having the possibility to trade ocassionally a powerful feature that will make my coding simpler for some unavoidable compilation delay. (Though I would of course prefer the compilation to be instantanous.)