Ruby (in which I've written no more than maybe 100 LOC) is great for what it does, but no one in their right mind is going to build a 10 MLOC aircraft-carrier control software in Ruby. Ruby's main goal is fast prototyping and fun initial development, a goal which it accomplishes beautifully. It is not a language for big engineering undertakings. But Scala tries to compete with Java, and you would write a 10 MLOC aircraft-carrier control software in Java. Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is.
I don't have a problem with Scala as a Ruby replacement. I do have a problem with it as a Java replacement.
> Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is.
If you are writing massive software to handle comprehensive control for an aircraft carrier, you'd better be writing it in loosely-coupled components with well-defined interfaces, or its going to be a maintainability nightmare no matter the language features.
If you are doing that, Scala's flexibility lets you, internal to each component, take the approach most suitable for the team responsible for that component addressing that components requirements.
I can see where Scala's flexibility could make a bad situation worse if you are writing an enormous piece of software but not doing it in loosely coupled components but instead doing a tightly coupled nightmare -- the OO equivalent of spaghetti code -- but, even though it might be less of a disaster, that's still going to be disaster in Java or C#, too.
I don't have a problem with Scala as a Ruby replacement. I do have a problem with it as a Java replacement.