> I am really not. My claim is a general one about Scala's kitchen-sink design philosophy, and why it's inappropriate for an "big engineering" language, as opposed to fast development languages like Ruby or Perl, yet it is you who insist on focusing on detail, which is part of the problem. So I responded to the detail.

And that claim is just not defensible in any kind of way.
Have a look at C# and C++. Both of them are magnitudes more kitchen-sinky than Scala by pretty much every measurable metric. Both of them are considered to be “big engineering languages”. Don't believe me, look into the spec.

Scala is certainly not the language which ships features which have been explicitly designed for working with the MS Office API for example. I can give you dozens more if you want.

> You are most certainly wrong here, though I can't prove it. You're forgetting that 99.9% of Java code is not open-source. In the organizations where I previously worked we used annotation processing where needed.

Well, there is certainly Scala code which isn't open-source, too. That doesn't mean that looking at the existing, available software out there is not a reasonable metric.

Anyway, even if that point was wrong, I have mentioned a lot of issues concerning Java's annotations processing and pretty much every item should be a deal-breaker if the goal wasn't to ship a failed experiment. People use Java annotation processing, because the alternatives are even worse, not because Java annotation processing is so great.

> Those brightest minds are usually the brightest minds in PL research. I don't think it's a coincidence that most of the languages designed by them, while brilliant in some respects, are not widely adopted in the industry.

Those are the brightest minds which shipped most of the stuff which made C# great. I wouldn't call C# PL research by any means.

> while other areas, like developer productivity, I find to be the wrong problems to focus on.

Developer productivity is certainly not the sole focus of Scala. But developer productivity means that people have more time to look at the hard problems they are trying to solve instead of fighting the language and shipping the business value they are paid for instead of wasting time on unrelated issues.

A language which has e. g. concurrency done right, but is so painful to deal with that everyone writes single-threaded code to get home early, is completely useless.

> but a language that makes collections the domain of experts without at least fixing the real hard issues, is just plain misguided.

Scala's collections are the most pleasant ones I have worked with and I think most people will disagree on that.
I also think that Scala's trade-off on letting the library authors solve hard problems once instead of letting every user deal with them on their own each and every time they use it is a reasonable trade-off.

In other languages you would probably have to implement every operation yourself if you wanted to define a new collection type. Mostly tedious, error-prone work. In Scala instead, you understand the CanBuildFrom facility once and get almost the complete implementation for free, overriding only the operations you care about.
Note that understanding CanBuildFrom is a one-time effort, while in other languages you will hit those issues every time you want to create a new collection type. Again, seems like a reasonable trade-off to me.