I think you've nailed it perfectly that Scala imposes as few constraints as possible. This leads to an oft-repeated criticism that since there are a dozen ways

I think you've nailed it perfectly that Scala imposes as few constraints as possible. This leads to an oft-repeated criticism that since there are a dozen ways to accomplish the same thing, it is hard for a newcomer to be productive quickly or to know what the "best-practice" is. However, this same flexibility allows an expert user to make specific trade-offs. In coding Scala full-time for a year, and writing an open source library [1], I never found myself saying that "I wish Scala had feature X"; but more importantly, I certainly never said "I wish Scala did NOT have feature X." Indeed, it seemed to address so many deep problems with Java. One loud complaint is lack of reified generics on the JVM, but this is easily addressed in Scala using TypeTags (2.10+). I like your musical instrument analogy, and to steal it, I would say that Scala allows you to be the composer rather than the musician. To be an effective composer, you need to know the qualities of all the musical instruments so they can work together harmoniously. You can write a beautiful symphony, or you can create horrible noise. But the power to do so lies with the developer/composer. That said, arming your large development team of average developers with such powers might indeed be asking for trouble. That's why Rod Johnson, in his recent Scala Days address [2], challenged the Scala community to address this problem if Scala is to be the "next Java". [1] http://saddle.github.io/ http://saddle.github.io/ [2] http://www.youtube.com/watch?v=DBu6zmrZ_50 http://www.youtube.com/watch?v=DBu6zmrZ_50