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

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?)

Neff

Just in case anyone misinterprets the phrase "in anger," it refers to the use of something in actual service towards for its intended purpose, as contrasted to practice usage. The phrase is not a qualitative judgement, per se. It may be obvious to everyone, but maybe not. – Nashom

Answer 1

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.

Fanchie

Answer 2

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

Tarlatan

Answer 3

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.

Northumbria

Thanks, Tristan. I'm now developing most new stuff in Scala, which is a bit of a learning curve but (probably) worth it. I've found that I'm still using familiar mechanisms from Java world to aid building and deployment (i.e. Ant and Spring). I guess I need to spend a bit more time getting familiar with the Scala alternatives – Neff

Answer 4

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.

Kathleenkathlene

Is "load some classes and execute methods" a bit vague? We're not all rocket scientists you know ;-) – Neff

Answer 5

See also: Real-world examples of Scala applications?

Danitadaniyal

Answer 6

I saw this on related links, and figured I'd chime in, now we're a couple of years down the road.

IDE support has improved a great deal, IntelliJ 11 has pretty good Scala support at this point. Syntax highlighting works great, though debugging can still be a bit annoying.

SBT looks like it's quickly replacing maven or ant/ivy, and thank god, SBT is much easier to work with than Maven, and suits Scala much better. IntelliJ for one also has an SBT console, and combined with interactive debugging can make debugging in Scala go very quickly indeed, though in all honesty, with syntax highlighting now getting really good, the amount of debugging I find that I need is greatly reduced. Scala just flows much better than Java, and seems to lead to much less error-prone code.

Database interaction still seems a bit up in the air, but there are a few frameworks out there that aren't bad and can get you working with a database one way or another pretty quickly.

Third party libraries and frameworks abound at this point, and of course you can still use any plain old Java third party library.

At this point, I'm left asking the question: why wouldn't you use Scala or another next-gen JVM language for a project? And though the simple answer is that many devs just aren't ready to deal with Scala today, in all honesty, they need to get their head of their collective asses and get in the game, and a company mandating it's usage will go a long way to making that happen (all of us need a push sometimes to get back in the game). In addition, if you're doing any kind of "enterprise" or high-volume development, and you don't understand functional programming and can't figure it out, do us all a favor, put down your IDE, or god-forbid vim, stick to scripting or find a new career path.

There are many high profile companies leveraging Scala today, the most public of which is probably Twitter. They have also contributed some of their frameworks into the open source world too.

Keffer

Answer 7

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?

Orogeny

I think moving to Smalltalk now would be a dead end. That's really not meant as a flame; I love Smalltalk (although I was never an advanced user). But I think it would be a mistake to introduce it into my workplace. – Neff

Could you address some of the specifics of the question re: Scala? How did you find the transition (assuming you were a Java programmer)? – Neff

Answer 8

I used it in "trial anger" once, to load a few gigabytes of data (a fairly light workload for what we do). I was hoping it would have higher performance and less memory overhead than PyPy. It failed BADLY, on the memory usage. So badly I was horrified, embarrassed to have talked it up, and never looked at it again.

Helio