"I've looked at Scala. I think it's really neat. I think it is Perl."

Or C++. Brilliant programmers will undoubtedly do brilliant things with it, but for a lot of folks, the word "multiparadigm" might as well read "radioactive." It's true (as someone above noted) that you can use a useful subset of the language and discard the rest, but weak programmers seldom choose correctly, and so we're left with steaming piles of spaghetti everywhere.

Ten years ago, I would have been thrilled reading Odersky's book. Nowadays, I die a little inside every time I see the phrases "language feature" and "syntactic sugar" in a language manual.

I had a job where we needed Java interop but wanted to do functional programming. The whole team ran on Scala, of course.

I hate to speak the Word of Curse, but this was why we used monads. They gave us something of an effect-typing system in which to wrap calls to side-effecting third-party libraries.

There's no limitation: you can use any 3rd party Java library from Scala. We do it in production for years, works perfectly.

It's true that Scala DSL is scary. As far I know soon (version 2.10?) you will have to add a compiler flag to enable some scary stuff. They are useful for library developers, but not too great for everyday apps.

Also you don't have to use the functional part. I saw plenty of code that looked like a nicer Java. You get less boilerplate and better performance - see http://news.ycombinator.com/item?id=2615096

Edit: The article you linked says: "... one call to some open source project that didn't worry enough about threading to even warn the user that the object is not thread safe." This would fail in any language, including Java.

You're right. But functional adds a whole new layer of "safety". The functional developer will think, "My code is functional, share nothing, messaging passing goodness. I'm fine." As but some new developer, keen on Scala, but not thinking about the older 3rd parties, adds a call from his functional goodness to the non safe, side effecting code. This will introduce a subtle, hard to trace bug. As a result, I'm not a big fan of the "it's compatible with Java" hype around these VM languages.

> I'm not a big fan of the "it's compatible with Java" hype around these VM languages.

The fact is Java interop is a fundamental feature providing great pragmatic utility as well as an absolute prerequisite for any kind of adoption of these languages. It's basically the opposite of "hype."

One of the major reasons why I went with Scala was the seamless Java interop.

There are 1000s of great and well tested components available. Apache, IBM, Yahoo etc. invested years in these, most of the time it just works.

There might be some libraries with issues, but so far I had only good experience with everything from security (bouncycastle) to PDF processing or geocoding.

I don't agree. I think that interopt should be at a higher level, like services. Putting the ability to integrate code not written for your paradigm is problematic. Pragmatic, but still problematic.

It's a lot like Node.js. Why Javascript? Because it is so self contained that it is impossible to use code that violates the paradigm because its too new. When the designer of Node looked at using straight C or another language, the legacy threat put him off. Same thing here.

> I don't agree. I think that interopt should be at a higher level, like services. Putting the ability to integrate code not written for your paradigm is problematic. Pragmatic, but still problematic.

I think if you look at just about any common example of idiomatic Clojure code you'll find Java interop sprinkled all over the place. People aren't going to reimplement all those libraries in Clojure, Scala, or whatever other JVM lang you're targeting. Seamless interop is a prerequisite. I think most Clojurians feel it yields far more benefit than any problems it might introduce.