I spent a long time trying to get the issue raised back in 2009. http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/08/

I spent a long time trying to get the issue raised back in 2009. http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-requirements.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-req... Key to both of these was 'real' backward compatibility (i.e. the compatibility between versions like 2.8 and 2.9, not the patch level compatibility that exists at the moment). I'm not moving the goalposts here; the issue is that having 2.8.x compatible with 2.9.y (or 2.9.x with 2.10.y etc) is a key point where Scala has failed, and continues to fail. Until this is fixed, Scala won't be enterprise ready. Rod's point (from his Scala days keynote) is that in 5 years Scala has a chance of being 'the' language, but only if it gets the backward compatibility issues sorted between 2.x and 2.x+1. My point was I made exactly the same argument almost 5 years ago and nothing has changed, and since the past is the best predictor of future performance it is a safe bet that in 5 years time Scala won't have solved that problem, and thus won't be applicable for large enterprises. This isn't a rant against users of Scala, it's a critique of the development plans that doesn't see this is a problem, or is happy to use Scala as an experimental playground that isn't likely to get widespread usage in enterprise. If you can fit all your organisation's development teams in a single conference room, these problems are never going to apply to you, since you can just mandate that everyone switches at a particular date. But for organisations with hundreds or thousands of developers such an all-in-one switch isn't feasible.