Over time, the ability to combine object-oriented and functional programming principles in one language has drawn large numbers of developers — and the companies they code for — to Scala. The language’s static type is famed for being concise and helping to eliminate bugs in complex applications, while its Java virtual machine and JavaScript runtimes allow the construction of systems with access to large libraries and ecosystems.
In part two of a two-part series, we spoke with engineers at three more Seattle-based tech companies to learn more about the advantages and potential pitfalls of adopting Scala at a startup or larger tech company.
Hiya uses a highly complex set of technologies in its ongoing defense of smartphones against spam and robocalls. By integrating with smartphone providers, Hiya is able to tell users who is calling them and allow them to block unwanted calls.
For adopting Scala within an organization, Principal Software Engineer Nodir Yuldashev recommends starting with smaller coding projects that will ship.
What have you built using Scala, and what criteria do you use when determining whether you’ll use it in any given circumstance?
I have built a variety of systems using Scala, ranging from consumer-facing web applications to petabyte-scale big data platforms. The one that stands out is a live digital video transcoding system which connects news broadcasters and local government agencies to thousands of traffic cameras across the country.
There are a number of factors that help to determine which functional language to choose for a given project, starting with strong community support on platforms like StackOverflow and GitHub. Being able to find an answer to a specific challenge in the language — and not having to reinvent the wheel — is a huge productivity boost.
Being able to express large algorithmic meaning and not having to write repetitive boilerplate code makes teams productive.”
What benefits and challenges does your team see in using a functional language like Scala?
The conciseness of the language comes to mind as one of the major benefits. Being able to express large algorithmic meaning and not having to write repetitive boilerplate code makes teams productive.
Managing dependency versions is a common challenge across different programming languages. The issue is prominent with Scala, where you have to account for different Scala versions as well — especially during Scala version upgrades.
How can larger organizations improve their adoption of functional languages?
In larger organizations, there are multiple barriers whenever you transition to a new technology or language. In those scenarios, I always advise teams to start with code that will not ship. For example, start with writing unit and integration tests with Scala in traditional Java projects. That helps build confidence in management level, and also helps developers get comfortable with the language.
Axon started life as TASER International and builds a range of software and hardware tools designed for use by law enforcement and public safety institutions. These include everything from TASER devices to body cameras to digital evidence management systems.
Senior Software Engineer Tamas Weisz said his team benefits from bringing a functional programming mindset even when coding in non-functional languages like Java.
What have you built using Scala, and what criteria do you use when determining whether you’ll use it in any given circumstance?
One of Axon’s products is Evidence.com, 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, including real-time information processing from Axon body cameras worn 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 as “functional programming,” some functional principles (immutability and map-filter-reduce, for example) have become second nature for us, so lots of our other codebases end up with similar code. In particular, lots of our front end 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?
Scala’s rich type system 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 versus the value being unlimited. In other languages, the options might have been to use magic values or null.
Ultimately functional programming is just a means to help write better software, not the end itself.”
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.
How can larger organizations improve their adoption of functional languages?
It’s 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 the functional mindset with you and 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.
AdColony’s mobile advertising and marketing platform reaches around 1.4 billion people worldwide. Headquartered in Los Angeles, the company was one of the earliest app developers on iOS. The company’s local office is located in Bellevue.
Director of Engineering Josh Conner said he generally hires engineers who are new to Scala, and as such must anticipate his staffing needs before they become acute.
What have you built using Scala, and what criteria do you use when determining whether you’ll use it in any given circumstance?
Almost all of our ad-serving and data-processing backend services are written in Scala. We have a fair number of folks who came from the JS world, so we’ll write quick one-off things in node.js sometimes. However, we’ve found that our inflection point where we start to wish we’d written something in Scala is less than 100 lines of code, so more Scala than anything else these days — especially now that sttp has a curl-based backend for Scala Native.
What benefits and challenges does your team see in using a functional language like Scala?
Types and a good type system are just the best. We had some organizational churn in the beginning of 2018, and inherited about 100,000 lines of Scala code with very little test coverage — but thanks to the Scala compiler having our back, we’ve been able to be very ambitious in refactoring and back-filling test coverage while still delivering stability and features for the company. Library support is also generally quite good: circe, Finch, PureConfig, kantan.csv, Monocle, ScalaCheck, Monix and refined — to name just a few — have all been a pleasure to work with.
As for challenges, our experience in hiring has been trickier than for more “mainstream” languages. We mostly hire developers who are new-ish to Scala but eager to learn, and so have had to invest more in the “long haul” — hiring a little before we actually need more people, building a team culture that is supportive of some learning and exploring.
We don't have any secret sauce — mostly, like many things, you just have to show up and do the work — and we’re definitely still learning every day.”
How can larger organizations improve their adoption of functional languages?
We had strong top-down buy-in originally, which is kind of like the “easy mode” version of adding new things to your tech stack. Beyond that, Scala’s a big language, so having a vision of “this is how we write Scala” — and then writing it down using a combination of a scalac flags, formatter rules and a style guide — has been super valuable.
How do you use implicits? How do you inject dependencies? Keep a list of “blessed” libraries for common tasks, like how to do data interchange and which test runner/libraries you use. That kind of thing. We don’t have any secret sauce — mostly, like many things, you just have to show up and do the work — and we’re definitely still learning every day.
.jpeg)
