How do you encourage your organization to move from Java to Scala? [closed]

Question

Has anybody's organization started the migration from Java to Scala? If yes, how do you do that? What can I do to encourage my colleagues to do the same?

Answer 1

Probably the easiest way is to first use Scala only for testing. In this case, you might even not have to tell your boss :-) If he asks, tell him "that's just my private test case, it's so much easier and faster to use Scala for it". Once you (and your organization) has enough experience with Scala you can start using it for the 'real' code.

Answer 2

From the companies perspective it is better to stay with Java if there is no distinct advantage that they will get by migrating to Scala. It is easier for them to hire Java programmers to build and maintain the application. You might just leave after implementing everything in Scala :-) No offenses :-)

Answer 3

Have your boss read experiences like this:

1. I'm currently doing most of my things in Scala right now. (I should mention that I think that Scala is the best thing since the invention of the wheel some time ago. :-D )

   In my humble opinion it is the only language which truly allows people to choose the best approach to a task without some unnecessary divide between (more) object-oriented and (more) functional approaches.

   Looking at the languages which claimed something like this before, I can basically see two competing language design camps:

   • The ones from the object-oriented side which saw that functional programming gained some traction lately and thought "Well, we don't really understand that functional thingie, but let's add some fancy syntactical sugar to our language, so we can claim it is functional too!" (examples: Java, Python)

   • Then the ones from the functional side, who thought "Well, our functional approach is far superior to anything else and that object-oriented nonsense is annoying, but let's put some additional keywords into our language, that will make our language escape academia for sure!" (examples: F#, OCaml)

   Scala's designers unified many approaches coming from both sides and created some well-designed language, which is - in my humble opinion - the biggest difference to other languages, which decided to take the "Frankenstein" approach to programming language design.

2. Having done only smaller things with Lift yet and only superficial experience with Rails and Django, I have to admit that most of the time when I wondered why something in Lift worked differently from what I expected, this was due to the fact that my expectations were flawed and Lift's approach superior.

   Lift is certainly no "easy introduction to Scala" but learning how Lift works was almost as rewarding as learning Scala before it.

   The ability to have a "clean" view without any logic in it is a great improvement to other frameworks which claimed the same, but fell short of it. Scala's XML literal support makes it possible to verify the well-formedness of your response: The compiler will prove at compile time that you only emit well-formed XML to a client.

3. Lift is viable technology and at the moment the only real approach if you want to build web applications which look, feel and behave like "real" desktop applications without writing insane amounts of code yourself.

[ Source ]

Answer 4

Over the past two years we've progressed a fair way along this journey at guardian.co.uk - our Open Platform is built on Scala, our core CMS (originally in Java) is gradually incorporating more Scala (we're soon moving from Maven to SBT for our build) and it's been a wonderful experience - really invigorating our devs, some of whom were becoming a bit jaded with Java :)

I'd encourage you to read these two articles about our transition, and maybe use them as supporting evidence with your pointy-haired:

http://skillsmatter.com/podcast/home/how-we-moved-from-java-to-scala

http://www.infoq.com/articles/guardian_scala

Some quick tips:

• Start by writing your tests in Scala - that way you can get familiar with the language, increase your confidence in it, and not have to conquer any fears you might have about adding the runtime to your production servers straight away.

• Don't ask for permission to try new technologies. Better to ask for forgiveness if you have to :-)

Answer 5

This question dove-tails in another question. That is for what kinds or projects does migrating to Scala provide added value? I do Java day my day job, but dream about the day I can use Scala "in anger".

A couple answers to my own question:

• Problems for which Actor based concurrency would provide great benefit (Akka)

• Web applications than have data pushed to them via COMET (Lift)

Any other insights or better yet experiences?

Answer 6

I'm writing tests for my Java apps in Scala and agree that it's a good place to start. My test coverage is better because it's quicker and easier to write them (also since I get to use Scala, I willingly focus on writing tests more).

I've also started doing prototypes and throwaway POCs in Scala pretty much exclusively. I try to make managers and supervisors as aware as possible that I used Scala for these one-offs and emphasize that I was able to get something up and running quickly because of Scala. We needed (well, kind of needed) a web app to track our holiday party white elephant game - 1.5 hours with Scalatra and MongoDB and my entire department is seeing this app and asking about it. Let's face it, you'll never get anywhere describing to managers how much more expressive the language is or that its concurrency model is so much better. But if you show them you can get more done more quickly, you gain ground.

But I think the biggest piece is getting developers excited about Scala. I'm sure we all work with developer who don't actively keep up with new technology, and sometimes it's hard to get those folks excited about doing anything new (why, I really don't understand). Showing those folks some benefits of Scala (try the REPL) is key. If you get enough developers buzzing about the same benefits of productivity, then you're far more likely to get Scala officially adopted in your organization.

Spreading the word and getting that grassroots effort rolling is my key goal in 2011. We shall see how it pans out, because I can't wait for the day I get to use Scala for the bulk of my work.

Answer 7

I'm wondering why choose one or the other? Why decide to throw Java out the door and go Scala all the way?

There is no such thing as the perfect tool for the job. There's no reason to throw expertise in one language out the door completely and replace it with another.

I wouldn't want to work (anymore) at a company that focusses on one language or environment, tbh. It's better to know many things and pick the right tool for the job.

Next to that, it's hard if not impossible to get your organization to switch over to Scala completely. Instead, I'd try to get some projects (or even parts of projects) done in Scala, instead of going for the all-or-nothing approach. You could, for example, opt to test your Java code with Specs2, which has a pretty nice syntax compared to plain old JUnit - and it's not complex, confusing and hard Scala code and paradigms either, just syntactic sugar around defining behavior of your application.

Answer 8

A good way is to demonstrate two versions of the same program. By doing that you can show to your colleagues (in practice) Scala's Expressiveness. Doing the same thing for other problems (XML, concurrency, etc.) can demonstrate the benefits of using Scala instead of Java for tackling specific problems.

Of course don't expect the migration to happen in one day. There are many problems that you might underestimate: The learning curve, the existing codebase, etc.