All about Scala

How and why we learned a second language

You’re tasked with building a brand new suite of networked APIs that let merchants easily tailor payments products to their needs. You know that these APIs will be accessed hundreds of thousands of times every second. Success is defined by how well they respond, making your programming choices critically important. For Access Worldpay, one such choice has been Scala.

When your platform is business critical and is being used continuously by a global customer base, it has to be reliable, safe and fast. For Access Worldpay, this requires its code to have a rock-solid ability to handle concurrent access, where multiple computations are executed almost simultaneously.

The need for a reliable concurrency model tends to favour functional programming over object-oriented programming. Like many developers, though, most of Access Worldpay’s team are trained in Java, which struggles to incorporate functional programming into its old, object-oriented paradigm. What to do?

Multi-paradigm programming

What they did was adopt Scala. It’s a modern programming language that’s highly compatible with Java but also far more dynamic. Its looser approach to backwards compatibility makes it “able to move faster and introduce more radical change,” says principal developer Alastair Donlon.

Most importantly, Scala incorporates both functional and object-oriented paradigms “equally well,” says Alastair: “It supports both these things as first class citizens, which is increasingly valuable.”

Feature-rich ecosystem

One important value is functional programming’s focus on immutability – i.e. once a function is created it cannot be modified. Within systems that are highly concurrent, immutability helps programmers avoid mistakes because it removes the potential landmine of concurrent modification to data, which can be problematic in object-oriented systems.

Scala’s support for functional programming also allows it to integrate other modern features, such as pattern matching, asynchronous programming and anonymous functions. These help make it a useful language for working on a highly scaled API platform like Access Worldpay. More specifically, they help make Scala the best way of integrating valuable technology, such as Akka.

Introducing Akka

Using concepts originating in the telecoms sector, Akka is a technology that uses the actor model to create a highly fault-tolerant system with code that is reliably concurrent and can also operate asynchronously – i.e. without blocking any other operation.

All these qualities are invaluable to Access Worldpay’s platform – so much so that it was the team’s interest in using Akka that prompted it to examine Scala in the first place. However, “Akka isn’t really built to be used from Java,” says Alastair: “Its technology is built in Scala, so it’s much cleaner and easier to use through its Scala API than its Java API.”

Efficient and flexible

Although Akka’s value has not yet been fully realised, the team continues to use Scala – largely because of its clarity, efficiency and brevity. “The code that you see is more valuable,” says Alastair: “You can see more of the functionality at once – there’s just less noise.”

What’s more, Scala offers developers more ways to solve specific problems. “In the Java world, there’s typically one way – the standard way – of doing something,” Alastair continues. “Because Scala supports both paradigms, you get a much broader perspective and programmers have greater freedom to solve a problem using whichever paradigm works best.”

Steep learning curve

That said, Scala isn’t easy. “It has a reputation for having a steep learning curve – and it does,” says Alastair. Much of this is the language itself: “Scala has very advanced syntax and features which can make it very implicit,” says senior developer Ignas Traskevicius: “Sometimes it is so implicit it can be almost impossible to understand.”

Besides this, Scala is a new ecosystem, with a different framework and requiring different project tooling. Furthermore, “a lot of approaches and patterns aren’t the same and that takes quite a bit of getting used to,” says Alastair. This was true even for engineers already conversant with Scala: “They had to learn how our quality approaches worked and how they could work effectively with our approaches around TDD and infrastructure as code.”

Where to begin?

Nevertheless, everybody at Access Worldpay now has some familiarity with Scala, either through a course or on the job. Some of them learned by using it to build an idempotency service to help merchants avoid duplicate payments, a process involving “a fair amount of learning,” says Alastair. Despite this, the build took around six months from initial concept to a production service, “which was pretty fast for Worldpay at the time.”

Most, however, have gained their experience through Gatling, a library built in Scala that can performance-test services written in any language. “Performance testing is very different to writing a production service, but it’s a good place to start,” says Alastair, who recommends it to other interested developers. “It’s something where you can play around safely with the language but still get value from it.” After that, he says, it’s time to start building services in Scala via frameworks such as Play or Lagom.

And learning Scala is worthwhile, for all its challenges, says Ignas. “Because it’s easy to write Scala code that’s very similar to Java code, to some extent you can mix and match the two, or choose the language that works best at the time,” he explains: “I think this will make it easier to suggest Scala as the main language to write production code in the future.”

Got any feedback or bugs to report?