Is anyone using Scala in anger (and what advice for a Java programmer)?

Question

I've been a Java programmer for over 10 years since starting off with Smalltalk. It's my opinion that next big languages are likely to be ones which run on the ubiquitous Java Virtual Machine. I'd like to take advantages of some of the features that Scala (among other languages) has - case statements for class hierarchies, closures, type inference as it will allow me to write more concise and clear (I hope) code. A bit closer to Smalltalk!

All the things that are second-nature in Java:

• Building with ant
• deploying applications/libraries into logical jars
• Great IDE tool support
• Writing GUIs (or having a Swing GUI talk to it via some kind of remoting?)
• 3rd party libraries/frameworks
• Configuration (properties, XML, Spring etc)
• DB drivers etc

I'm concerned that the difference between playing around with some pet project and actually making the leap to using it in anger in the workplace is a bit too much.

1. Has anyone made this leap?
2. Was it worth it?
3. What lessons did you learn?

(Obviously people are using Scala - but is anyone building actual, for the want of a better word, Enterprise applications?)

Answer 1

Yes, people are building actual "Enterprise" applications with Scala (and Clojure). Just do it.

Of course, people are also using Smalltalk, so if you like Smalltalk, why not use that?

Answer 2

I've added clojure to the software infrastructure used in the Kepler mission's science operations center. Right now it's there for doing interactive debugging; run the REPL, load some classes and execute methods in an ad hoc manner.

EDIT: OK, so "load some classes and execute methods" is vague. For example, we can load our crud classes and then execute method to convert one kind of spacecraft time into another.

user=> (import '(gov.nasa.kepler.hibernate.dr LogCrud))
user=> (def crud (new LogCrud))
#'user/crud
user=> (def shortCadences (.longCadenceToShortCadence crud 0 2500))
user=> (prn shortCadences)
#>

There are other methods that can be called to convert this time into other kinds of time formats which might be useful for debugging. We could make command line tools to encapsulate all this functionality, but there is no need to since everything is available from clojure.

Answer 3

Jonas Bonér for one: http://jonasboner.com/2009/01/30/slides-pragmatic-real-world-scala.html

Answer 4

I have used Scala on our existing Java infrastructure to query and manipulate large xml documents. Was not possible using the standard Java xml libraries or not as easily.

I was tempted to use it for portfolio performance calculations, but had already finished the Java version. A Scala version would have been easier to maintain as it is easier to translate the formulas directly into code.

Another area where you can sneak in Scala is with multithreading. Have no real experience with this, but it seems to be easier in Scala.

Point is, don't try to see it as a Java replacement for now, but use it where you can utilize it strenghts next to your existing Java code.

I used Intellij with the Scala plugin as an IDE, but it is not there yet. It is do-able in combination with the maven plugin and the console.

I'm also a Smalltalk programmer and love being able to use code blocks in Scala. Compared to Java there is less code, but still not as readible as Smalltalk code.

BTW, the smalltalk community is growing again thanks to the Seaside framework, so you might want to return

The things I learned or got a better understanding of:

• the use of constructors
• the immutable concept
• working with lists and recursion
• functional programming in general

So yes, I think it is worth it.

Answer 5

See also: Real-world examples of Scala applications?

Answer 6

I basically hit everyone on the head with Scala code in our last project, as I got sick of debugging the same problems caused by a lack of understanding of Hibernate + JBoss. (It's amazing, really. The developers who wrote the original system are still there and still get lost in Hibernate details.)

What we had -> a wacky system built mostly with a bunch of stateless EJB beans wired together with some hibernate code tossed together with some SQL. (We're an ASP, basically. The production cluster is fairly small -> only around 100 machines.)

What I did -> put together various REST-based services, where we redefined the RPC between some of the servers. This is making everything very easy to code, plus, implementing a public API into what was a system where no attention was paid to dependencies.

So far, we've started to deploy code in and out of JBoss instances with no real problems. The first time you try to use a Scala object in Java, you'll probably wrinkle your nose. But otherwise, nobody really noticed.

So far, it's been about 5 months since we really started. We've done a couple of major revisions, and subsequently are behind, but the system is far, far better tested than in the past. So, while we've had some bad ideas sneak in there while we were really learning the system, we've now been able to remove them all, and, get very close to production deployment. All in all, I'd say the typical dude needs 2-3 months to stop coding like a Java programmer, and get "familiar" with most of the standard libraries.

Writing JDBC code instead of an ORM system basically has thrown out almost all of our performance problems. The speed has been actually significantly better, but that was mostly because I was able to do everything I wanted with less real application code.

Tools I'm using:

1. Restlet : Very happy with this framework. Our restlet layer is outrageously trivial code.
2. JDBC -> note: we've tweaked what was basically there in the wiki
3. XML (and soon, JSON)
4. buildr, maven on a couple of projects I didn't want to convert (plus Nexus and Hudson). I'm experimenting with sbt, which is already very nice for scala projects.

We've had absolutely no problems with reusing any of the old java libraries, but we do tend to wrap them in scala-fied layers. Mostly just to write less code.

And the pimp my library pattern is by far the most important one to be familiar with. The "cake" pattern is nice, but you have to control instantiation, which sometimes isn't quite useful. I have also used Guice in a mixed environment, not really hard, either. But I find that mixing code is way less useful than I originally thought, though that's probably because I'm replacing a lot of really, really bad Java code.

My editing environment is mostly TextMate on OS X, but we deploy on Linux servers.

P.S. Yes, I know this is about 4 months old, but whatever. It's relevant, especially now that we have some experience.