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.
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.