[dkhenry]

A few things about this post.

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.

[timclark]

Steve's remarks on concurrency seem a totally fair observation to me, don't a large number of functional languages deal with concurrency through immutability and support that at the language level - I can think of Clojure, Erlang, Haskell, F# for example. The fact that it was possible to send a mutable message to a Scala actor made me extremely suspicious when I first used the language.

[rit]

It's a relatively well acknowledged fact in the community that Scala's builtin actors are heavily flawed. This is why many of us switched to using Akka.

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.

[timclark]

My personal experience in wrapping non-trivial Java libraries in Scala and Clojure is that with Clojure it usually just works and it works quickly. In Scala I am usually reduced to an extra hour or two of adding manifests to signatures until the compiler accepts it.

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.

[daniel_solano]

Interoperation with Java from Clojure is generally fairly painless. The largest exception that I can think of is if you are trying to integrate with a library/framework that is heavily object-oriented and requires class inheritance. Clojure is very opinionated on the functional programming aspect, and although it is generally possible to extend classes, it can be relatively painful.

However, if you are only using objects, calling methods, or even implementing interfaces, interoperation for Clojure is quite nice.

[nickik]

Even if the Actors are better, generally people still build programmes with lots of mutability. If don't start to build your application with concurrency in mind you will end up with problems later. With clojure you can be pretty sure that everything is threadsafe by deafault.

This is just how it seams to me from afar. I don't know if that is right.

[dkhenry]

Functional Programming does deal with concurrency with immutability. And thats how you should deal with it in scala. The fact that you can use mutable constructs in concurrent program is no more a flaw of scala then the fact that I can execute any pointer in C as a function is a flaw of C.

[sllrpr]

Many would argue that this is a flaw of C.