Back to news

Using Scala at Axon

By Tamas Weisz (Sr Software Engineer at Axon)

Published on

What cool tools and services have you built using Scala, and what criteria do you use when determining if you’ll use Scala (as opposed to other functional languages) in any given instance?

One of Axon's products is, our Digital Evidence & Device Management platform which allows our customers to access and manage their digital evidence, and manage their Axon devices. A large part of the backend services for this system is written in Scala, that includes real-time information processing from Axon body worn cameras in the field, AI training, analytics, reporting, core evidence workflow and access control logic, as well as services used by other Axon teams such as user and session management.

While we don't widely use other languages that one would commonly think of when hearing “functional programming”, some functional principles (immutability, map-filter-reduce, etc) became somewhat second nature, so lots of our other codebases end up with similar code. In particular lots of our frontend JavaScript code is written in a somewhat functional style (we use React, which encourages this style anyway).

What benefits and challenges does your team see in using a functional language like Scala?

The rich type system of Scala allows us to succinctly and precisely express the state of the entities for any situation: for example sealed traits are great for safely describing situations where a limit exists on some kind of value vs the value being unlimited (whereas in other languages the options might have been to use magic values or null).

Immutability is a useful tool as well: immutable locals help reason about the code locally, while case classes and immutable collections help ensure that no surprises happen to the data as it travels down and up the call chain. I think everyone who had ever had to debug a rogue setter appreciates how much this can simplify things.

Data processing with maps, filters, and reducers helps remove lots of the cruft that exists in the imperative counterparts of these idioms and clarify the intent of the developer. Less cruft means less opportunities to make a mistake, and focusing on the core of the data transforms generally makes understanding the code easier.

One challenge that I see is that while I'm personally fond of functional style data manipulation, for developers coming from different backgrounds it can take some getting used to. It's important to keep the code in a state that's easy to grasp to the rest of the team as well, because every previously unfamiliar functional idiom is a mental burden that takes attention away from understanding what's actually going on in the code.

How can larger organizations improve their adoption of functional languages like Scala?

Having a few smaller, successful projects written in functional languages can ease both developers and engineering managers into a new technology. This helps build internal know-how and confidence.

It's also possible to reap some of the benefits of the functional principles in a non-functional language. If a project decides to go with Java instead of Scala, you can still bring with yourself the functional mindset and (maybe with a help of a linter or style guide) stick to immutable data classes and collections (Lombok and Guava are two libraries that I found useful in the past), use stream processing instead of hand-written for loops, or use lightweight lambdas instead of fully-fledged function classes.

The important thing is to keep things to a level that the entire team is comfortable with, because ultimately functional programming is just a means to help write better software, not the end itself.