3 ms·
For scala 2 at least, the standard library is very heavy and the compiler of course relies on it. It has a god object, predef, that cascades massive classloadin
by norir 1y ago
For scala 2 at least, the standard library is very heavy and the compiler of course relies on it. It has a god object, predef, that cascades massive classloading if you touch anything in it. As a result, it is essential for latency to keep a warm jvm up to avoid reloading it.
Incremental rebuilds can actually be not too bad in scala when a warm jvm is used for compilation as it is by sbt and other scala build tools, but sbt also by default uses the warm jvm to run in process tests. This too can be reasonably quick but leads to problems if there are any resource leaks in the user's test suite.
Thus with sbt, one must either exercise discipline and care with tests to not leak anything or you will periodically have to restart sbt, which can be very painful because it is much heavier than the already heavy scala compiler.
It's a disappointing state of affairs because while there is a lot to like about scala, it is impossible to escape the bloat. Even if you opt out of sbt, the lack of modularity in the standard library forces workarounds, such as native-image, which had its own issues (including horrific build times for making native images and weak reflection support). Even if you or your org avoids the direct pitfalls, it is likely at some point you will end up debugging a dependency that doesn't.
I personally abandoned scala due to this bloat, which was a shame because I find it to have the best combo of expressiveness and pragmatism of any established general purpose languages.