Summary
Graham Tackley discusses how The Guardian switched all new development from Java to Scala, why they did that, what were the benefits and the problems, and why they did not choose Python+Django.

Sponsored Content

Bio

Graham Tackley is the Web Platform Team Lead for guardian.co.uk and a Pragmatic Scala Adopter. He and his team make sure the website can scale and evolve the platform to enable reader engagement in new and innovative ways. Recently, most of his time has been occupied with the Open Platform Content API which provides access to all of the Guardian's current and historical web content.

GOTO Aarhus is the enterprise software development conference designed for team leads, architects, and project management and is organized by developers, for developers. As software developers and architects ourselves, we wanted to craft the ultimate conference.
The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community, staged in an intimate environment needed to support as much learning and networking as possible.http://gotocon.com/

But mostly it doesn't matter that your variable type is List<String> or ArrayList<String> because you're only ever likely to be calling methods defined in the List interface. Where it matters, in Scala you can still define it thus:

val list: List[String] = new ArrayList[String]

OR

val list = new ArrayList[String].asInstanceOf[List[String]]

You're wrong that your Java version and the Scala version are similar in this respect: in the Java version you *always* have to specify the type on the left and right. Your example is being kind to Java. Consider this:

As you say: List<String> myList = new ArrayList<>(); // not: ArrayList<String> myList = new ArrayList<String>();seems to be semantically equivalent to val list: List[String] = new ArrayList[String]... in _this_ case, the Scala code is longer.

In your exampleval hLiftingWidget = GenericHeavyLiftingWidget[VeryHeavyObject]()Yes, of course, if you want the left (abstract) and right (implementation) types to be the same, 'val' is more compact.But it allows to write implementation-specific code easier (e.g. a method only in ArrayList, not in List) which is probably not always a good thing. When you read List<String> in a variable declaration, you know that the following code is not dependent on ArrayList or on another specific implementation. (It's not just "free" verbosity in this case.)

When comparing Scala to Java, just compare it to correct Java code.I think Scala is rich enough (SAM vs first-class functions, covariant generics,...) so that you don't have to use a trick to amplify the difference.(I see that several times in various Java/Scala comparisons.)</string></string></string><></string>

It's never been a real problem for us. We wait until all the libraries we use are published for a new scala version and then we upgrade. And it's just worked - there's never been anything other than trivial changes we've had to make to any of our codebases to compile with new scala versions.

For shared libraries, we cross compile against all the scala versions we have in use, using sbt.

Personally I prefer this to a backwards-compatibility-at-all-costs, which ends up with things like HttpServletRequest.getHeaders returning an Enumeration (effectively deprecated in java 1.2).

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.