I feel like this might be a prophetic litmus test of where to work.
Example: Is the company able to handle moving targets, or is the culture so fucked they marry things like JDK 1.4 because they can't handle basic evolution.
I disagree. It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. Different organizations have different priorities. Many times new versions give you features that are worth the effort taken to update. In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. It's flawed to say that this means the culture is "fucked up".
Scala simply doesn't move that fast and doesn't break that often. I can say that as someone who has been using it since 2.7. (Some of the thirdparty Scala libraries on the other hand will are close to giving me aneurisms ...)
At its current velocity, Scala is hitting a sweet spot in between improving language features and dropping cruft. The way you can change language features via imports is awfully nice a well.
Note that most of the major library providers for Scala jump on the new versions of the language while it's still in the milestone stages of development. Examples are scalaz and akka.
It's not just simple stuff either, often major libraries will have specific versions that work with specific releases of the language. No matter how well engineered your code base is, if you have to change apis that you use throughout your code as well as cope with languages changes too, it's going to be a lot of work for relatively little business value.
> It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features.
How is this different from e. g. Java? Developers pick a version which works for them and stick with it until it makes business sense to upgrade.
> In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems.
I've been developing Scala full time since 2.7. I have not had a release yet that didn't involve changing code to recompile to each new version.
I also have Java projects that were written in pre 1.0 releases that have updated to 1.7 without a single code change.
This is due to a different set of priorities. Each of those priorities has different costs and benefits but to act like Scala's lack of backwards compatibility doesn't have a cost is unfair.
Example: Is the company able to handle moving targets, or is the culture so fucked they marry things like JDK 1.4 because they can't handle basic evolution.