Experiences of working with Scala

The Joy of Scala


People embark on their Scala journeys in different ways. Scala Technology share their experiences with JAXenter……..

Picture a sunny morning in 2004: a light and airy office in a
village in rural England where a group of people are seeking the
ideal development language. An innate and intuitive distrust of
proprietary options; a less visceral – but nonetheless real –
dislike of PHP; a positive feeling for some aspects of

Java but a sense it could be cleaner, less cumbersome and
altogether “better”; an evaluation of the lesser-known and more
exotic languages; and an evolving admiration for, and growing
recognition that there was one: expressive, fast, safe,
maintainable, scalable. It had to be Scala!

Looking back this was an ambitious but risky step. In those days
Scala was not the stable, tried and tested solution to our problems
it is now. The compiler was buggy. There were few libraries,
limited documentation and even less sample code. The community was
very small but punched above its weight to support other members
when they encountered problems. But we all knew that we had found
something good and, despite these early teething problems, it was
worth sticking with. With greater knowledge came intellectual
satisfaction rather than contempt.

As time goes by ….

Over the last five odd years we have completed a variety of
projects, for many clients in many different environments and
domains. Each has brought its own unique challenges, but from each
assignment we have learned: where to start; how to integrate Scala
into a multi-language, multi-paradigm environment; how to build
Scala web applications that scale and are easy to replicate; design
patterns and “best practice”; about Scala libraries and what makes
them more or less general and flexible. And also of course how to
construct the development environment and team structure that makes
us most effective and efficient.

Health warning

What follows in an attempt to pass on some of the things we’ve
learnt. We’re not saying all these will be right for you in your
environment, that they’re the best ways of doing things or that
they will work for everyone. This is just what we’ve picked up
along the way.

Why we still use Scala? The benefits.

The benefits we originally sought to obtain from Scala have,
largely, been realised but as we’ve been through full development
cycles we’ve found that some of the delights of using Scala are
both more subtle and more profound than we realised.


Scala is hugely capable at giving the programmer more power to
express code in the way he wants to think about it. Be it through
case classes, custom extractors for pattern matching, user-defined
operators or just utilising existing Java libraries in more
eloquent code, the language has charisma!


From expressiveness comes conciseness. Or at least, the option
to be concise: it’s for the programmer to decide whether to
directly mirror the verbosity of Java, or to imitate Haskell’s
terseness. Unsurprisingly, most users will pick a happy medium!

Scala code is generally a boilerplate-free zone. There is often
a tendency amongst certain developers to get a misplaced sense of
satisfaction from writing boilerplate code: writing hundreds of
lines of code without thinking about them seems like productivity,
but it doesn’t take a genius to work out that it’s basically wasted
time and completely contrary to the DRY (Don’t Repeat Yourself)
principle, maybe the single most important consideration in
software engineering.

But why? If you find perpetual repetition in your code, it’s
most likely a deficiency of the language you’re using. A few years
ago, Jean-Paul Nerrière of IBM identified 1500 of the most useful
English words and combined with a simplified English grammar he
created a language called “Globish”. It’s

great because it makes it very easy for non-English speakers to
communicate. But just imagine how frustrating it is when you want
to talk about your cousin but have to refer to her as your father’s
sister’s daughter every time you mention her. Like Globish, Java
simply doesn’t have the vocabulary or constructs to avoid this

What might take several lines of code in Java, or the use of a
common design pattern, might be expressed in a single line of
functional Scala code. This not only makes it quicker to write but
also makes it easier to pick up someone else’s code and understand
it, not to mention old, long-forgotten (and of course undocumented)
code of your own…

Let’s not overlook the other edge of this sword: that with
conciseness can come incomprehensibility: anyone who has dabbled
with Code Golf
will know the sorts of symbolic soup your code can resemble if
conciseness is your only master. Scala is all about striking that

Static typing

Many beginners find static typing a pain: You’re trying to get
something working quickly, but the compiler is just whinging about
the sloppiness of your coding. Sure, the code might have worked,
but you wouldn’t have known without actually running it. But “oh!,”
I almost hear you crow, “I wrote a unit test first to check

I’m going to be blunt about this: can you seriously tell me you
would rather write a unit test than have the compiler tell you your
program is never going to work, so there’s no point even trying
(and by the way, your errors are here, here, here and here)?

After a while static typing will become the biggest timesaver in
your development cycle. It’s the crux of what gives Scala
developers so much confidence to develop. Instead of developing in
tiny iterative steps, Scala mitigates the risk of making tremendous
refactorings across multiple crosscutting concerns. If you’ve been
using Scala for long enough, you won’t think twice before embarking
upon a significant rewrite; knowing that the Scala typechecker is
there as an immensely powerful safety-net gives you the confidence
to naively shuffle code around, safely assured that – although the
compiler might give you a long ‘to do’ list of errors – once you’ve
fixed them, your code will just work.

Speed and Robustness

Scala’s combination of expressivity and static typing means in
practice that it takes far less time to develop working
applications, from tiny toy code, to heavyweight applications.

From a business perspective, this means you have a choice of
doing more with the same resource, to develop applications more
quickly, or do the same with less.

The greatest efficiency and effectiveness gains are made with
the addition of frameworks, customised libraries to your domain, a
well set up development environment, a well structured and
appropriately-skilled development team and robust architecture.

Native Scala libraries have been a while coming. This is
possibly because existing Java libraries have been adequate for the
purpose, but more likely because building good, reusable and
effective frameworks is hard.

It’s a common criticism of Scala that it’s too complex. And it’s
true that Scala’s feature list is not small. Most Scala developers
probably use less than half of the features available to them. But
unless you’re building libraries or doing academic research, this
is all that’s necessary: all the productivity benefits stem from
Scala’s everyday features, not from the more esoteric details. If
you don’t need them, don’t use them (and you won’t even know
they’re there).

The Scala development team, ably lead by Martin Odersky, are
very conscious of Scala’s position at the intersection between
cutting-edge academic research, and commercial pragmatism. Much
thought has gone into the design of the language to make it
coherent and practical across the length of the learning curve, by
means of appropriate documentation and meaningful error

Java compatibility

In case you had made it this far without realising, Scala and
Java are compatible. A fundamental premise of Scala’s development
has been full compatibility with Java. That is to say, you can use
Java libraries in your Scala code, and you can use Scala libraries
in your Java code.

But how is this possible, given Scala’s vastly superior
capabilities? Some ingenious ideas have gone into making Java’s
many warts evaporate when referencing Java from Scala. There’s no
need to cloud your mind wondering about special cases for
primitives or boxing; Scala makes it an implementation detail.

But what about in the other direction? Well, unfortunately
there’s no water-into-wine miracle to suddenly turn Java into Scala
just because you’re using Scala libraries, so if you’re calling
Scala code from Java, you have to do it in the usual Java way, and
you may need to know some implementation details. But let’s not
forget that compiled Scala is plain old Java bytecode, and the Java
compiler can’t tell the difference.

Developer Satisfaction

This should not be overlooked. Scala is simply a far more
satisfying language to work with. On top of the added confidence
you get as a programmer, there’s never the sense that you’re
fighting the language to be productive; the code just flows.

The job of programming is fundamentally that of translating:
programmers are given a human description of a problem which needs
to be solved, and they convert that into a form the computer
understands. Humans aren’t getting any better at framing their
problems in code, but Scala is making the computer better at
understanding human language. This reduces the work involved in the
translation; the steps necessary to encapsulate the problem as
code, so the programmer can spend less time solving the syntax of
the problem and more time solving the semantics.

Morale and productivity tend to be higher in Scala teams and the
community is stronger because it’s simply a more satisfying way to
code, and seeing development happen more quickly makes the
productivity more tangible to the development team.

Competitive edge

We believe that all of the above virtuously conspire to give us
an edge (as Scala application developers and consultants), and an
edge to our customers (reliant on speed of delivery, speed to
change, quality and cost effectiveness).

How do I get started?

Clearly there are a number of different starting points and each
will have its requirements: a startup will have different needs
from an established organisation’s Java development team. However
there are a number of common questions that occur: What do I do

Analyse and prioritise

Many organisations will have a backlog of development needs: new
features, new applications, new releases, major and minor changes
along with a pipeline of projects that are desirable but have not
passed business-case hurdles. Whilst it is our core belief that in
the long term most of these would be better performed in Scala, the
key issue is one of prioritisation: where is the greatest benefit
to be attained soonest, and with the least risk?

Sadly there is no easy answer to this question – we have
developed a process, enabled by software (developed in Scala, of
course) to facilitate a development team (senior technical
managers, line-of-business owners, and developers) identify the
best projects to start with. The key considerations are:

• Complexity

• Risk

• Business criticality and impact

• Performance requirements

• Scalability

• Scala expertise

• Quality

• Timescales

• Team development

Analysis of these factors allows us to produce a portfolio of
candidate projects to migrate to Scala.

Assess and develop your organisation

You might have a great team of developers, but which of them
have the motivation and propensity to become great Scala
developers? Your prioritisation above will give you a good idea
about which projects should use Scala first, and some idea of the
resources you will need but what team will be optimal to deliver
now and in the future?

Do you already have the Scala resources or are you re-training,
hiring or seeking to bring in outside expertise to help? You may
find that a lot of your Java developers are secret Scala devotees
in their spare time.

Many organisations may choose to bring in Scala experts at the
start to work alongside their Java developers, to help set things
up, get things going and to act as mentors once the team is running
on their own.

Create your development environment and

Despite being relatively new, there are already a great many
open-source frameworks, methodologies and tools on offer from the
Scala community to help you develop your first Scala application.
Each has its own merits and we don’t believe there is a
one-size-fits-all answer. You could ask one of your developers to
research and recommend an answer, or you could seek advice from a
Scala specialist to recommend the optimal toolset, environment and
process based around your existing setup, requirements and future

Position Scala within your environment

Most organisations have a heterogeneous environment involving a
range of technologies which have been well integrated to fulfil
their needs. These include databases, application frameworks,
business applications, security infrastructure, web interfaces and
multiple layers of messaging and communications services and

You will need to understand where and how Scala needs to
integrate; how to achieve the greatest benefit from it; how to
insulate your application from the future, and all the uncertainty
that brings.

Operational management and support

Having reached the milestone of having initial applications
developed and running, they need to be supported and managed. Scala
fits comfortably into a Java environment, though there are still
specific support considerations. Scala applications can be
considerably more robust than other languages, though – like any
system – require support and maintenance. This could be developed
through an internal operations team, while second and third level
support may be provided by the development team or a third

Quality assurance and audit

Any new Scala development, especially by an inexperienced team
should be quality-assured and audited. Scala’s flexibility offers
many possible ways of implementing the same project, but each will
have different performance characteristics, and some will be easier
to manage than others. Scala goes a long way towards facilitating
best practice in software development, but there’s more than one
way to skin a cat. It’s not always clear which architectural
approach is the most appropriate from a perspective taking into
account long-term considerations like maintainability and future

Development support

The success of many projects relies on the expertise and
experience of external resources. Bringing in vital skills can be
important at critical times on all projects. The Scala market is on
the cusp of great things, but it’s not yet as mature as the Java

More mature Scala organisations

Many organisations have been using Scala for some time. Perhaps
not for all their development projects but with some elements of
Scala mixed with the major Java applications. Very few have the
experience of evaluating how effective their Scala implementations
actually are, how they are performing compared to how they could
perform, how their teams are working and how efficient their
development environment is.


We believe that developing in Scala offers significant benefits
to most organisations, and for organisations already using Java,
Scala offers low-hanging fruit as a boost to productivity.

These benefits are obtainable almost immediately but will be
even more applicable in the long term as well. We believe that
maximising the benefits of Scala implementation relies on the
skills and experience of the team involved.

exists to help organisations maximise the benefit of
their use of Scala. Working closely with Martin Odersky and the
Scala team in Switzerland, Scala Technology promotes the use of
best practice in implementing Scala in industry. Led by the team
which launched the first commercial applications in Scala in 2004,
our team has the tools, processes and experience to develop teams
and applications that can truly take advantage of everything Scala
has to offer.

Jon Pretty is a technologist, developer, systems architect and Scala evangelist with over five years' hardcore Scala experience under his belt.
comments powered by Disqus