It is also why there are currently plans to integrate Akka actors into the language itself, replacing the builtins.
He does acknowledge that "It could become EJB3" which is a far sight better. But the tone of the rest of his post genuinely seems in conflict with this sentiment.
Another big piece of Scala which makes it a tremendous win over using say, Erlang, Haskell or F#, is that it integrates well with existing Java code. Many shop have been able to do new development in Scala while keeping and leveraging their existing legacy Java codebase. Something that wouldn't be properly available from these other Non-JVM languages.
Clojure of course is JVM based as well; however I'm not as familiar with it and I'll admit I don't know how well it does or does not work with existing Java Code. I do know that a few MongoDB + Clojure driver authors have had issues w/ certain aspects of our Java driver in wrapping it which seemed rather trivial. Not an indictment of Clojure, just the only view of Java compatability I've seen which anecdotally leads me to believe Scala has stronger integration.
Finally, I can't agree enough on the need for modules. It really is a major pain point... but I'm not sure it's one that we can easily fix at this point. I'd still love to see us (The Scala Community) try, however.
I am disappointed with Scala and having lived through EJB 1, EJB 2 and then onto Spring and EJB 3, I agree with Steve it makes me feel exactly the same as I felt about EJB 1 and EJB 2 - that is I am being sold overcomplicated technology as a panacea. I want a powerful language with a simple syntax, for example Lisp, ML or Haskell, not a powerful language with a complicated syntax like C++. Does Scala really want to be known as Java++?
I think the criticism of implicits is valid and should be addressed by the scala community, it is a frequent occurrence for me to be left scratching my head when reading code because something is bringing in an implicit declaration unbeknownst to me.
Also one complaint not made by Steve is compile times, reasonable in SBT, unreasonable using the typical build tool used in legacy Java projects.
However, if you are only using objects, calling methods, or even implementing interfaces, interoperation for Clojure is quite nice.
This is just how it seams to me from afar. I don't know if that is right.
firstly it is never good when you start out a discussion by saying now I know people will disagree but thats because their bigoted zelots. Its kind of disingenuous to attempt to post a technical dissent filled with personal opinion and preface it with that kind of clause inevitability allowing you to label any dissent as "See those scala zelots are at it again"
That being said this is an article that attempts to raise technical problems with scala but really just list a few of the authors own personal gripes with the language. In order here are his complaints
1. Scala doesn't have a rigid versioned module system 2. The functional way of doing concurrency isn't how I like to do concurrency 3. The scala community isn't helpful enough for me 4. The type system is too powerfull 5. The syntax is too flexable 6. There aren't enough tests in the compiler test suite
Its alot of the same thing I have seen when people try to list "The" problems with the language and not "Their" problems with the language. Technically there is only one argument that could even hold water thats about the module system . Which if he really needs a module system for his work then that is a technical limitation of the language and he might consider using a better tool for his job. The rest of it however is just nonsense and personal opinion pretending to be technical dissent.