DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Andreas Jim
Andreas Jim

Posted on

Scala: A Love Story

I wrote my first programs when I was 14, in Basic on a Sinclair ZX81. Now, looking back at almost 30 years of writing software from 3-line scripts to enterprise content management systems and microservices in the cloud, maybe a handful experiences stand out. Starting to program in Scala is one of them.

Until 2010, I had programmed mostly back-end code, and almost exclusively in Java. I had used quite a few other languages, it was just that none of them seemed to have any clear advantages. Java came with a huge ecosystem of frameworks and libraries, and I felt like the verbosity was an adequate price to pay for type safety.

At one point I had the opportunity to be the technical lead for a large in-browser application. We started out using plain JavaScript while trying to adhere to the functional paradigm: Avoid mutability, favour evaluation over execution. In the beginning this worked reasonably well. The codebase was small, the code was concise and easy to read, we were able to deliver features at a remarkable pace. But when the codebase grew and more developers joined the team, our productivity started to decline. We had to add (and maintain) more code documentation. It was nearly impossible to change something in a core module, there were just too many potential usages, particularly in a dynamically typed language that supports implicit type conversion and allows things like something[methodName]();. In the end we ended up migrating the critical modules to TypeScript, which improved the situation considerably. Lesson learned.

But the experience from the early days of our JavaScript project stuck with me. It felt like with Java, and with the frameworks we used, there was no linear relation between the complexity of the models or logic you wanted to implement, and the amount of code you had to write. Even the simplest tasks required a lot of boilerplate. The nagging question kept popping up in the back of my mind: Why can't we everything at once: Concise code, type safety, record types, closures? There had to be something better.

I purchased the very entertaining book Seven Languages in Seven Weeks. Although I found Haskell fascinating and tempting, I knew it was unrealistic to introduce it in our company. Scala on the other hand looked like it could be the holy grail: All the characteristics I was looking for, no need to abandon the JVM and its cornucopia of tools and libraries, and the possibility for coexistence with Java and therefore incremental adoption. After implementing some simple programs to identify any immediate risks of committing to the language and its ecosystem, I started to introduce Scala in customer projects. Luckily, I was fortunate enough to work with open-minded, curious, and ambitious team members who were also experienced enough to appreciate the benefits of the language. We immediately applied our experience with functional programming, and embraced immutability. Libraries like Slick and Akka HTTP (we actually started out with its predecessor, Spray) made building database-backed REST services a breeze. And the resulting code was robust and highly maintainable. Scala's expressive type system and type inference made it easy to build a restrictive, consistent domain model without bloating the code. There was virtually no overhead. Any boilerplate could be easily abstracted out. In the end, the application code felt natural, concise and elegant. Programming was fun again.

The name Scala is portmanteau of scalable and language. This is far from a marketing ploy. The language is designed from the ground up to excel in the full spectrum from 3-line scripts to vast, high-performance distributed systems. From my experience, I would attribute this to the following characteristics:

  • Scala's syntax is particularly suited for building APIs and DSLs.
  • Its expressive type system (higher-kinded types etc.) encourages abstraction and generic programming.
  • Scala supports functional programming, and functional programs are inherently composable.
  • There is are many excellent libraries that leverage these features.

Scala has sparked a huge ecosystem of very high quality libraries (Cats, Scalaz, shapeless, to name but a few). I think a major reason for this is that Scala attracts developers who value the advantages of the JVM, but are fed up with the limitations of the Java programming language and understand the benefits of an expressive type system and functional programming.

Admittedly, it is not trivial to transition from imperative to functional programming. At first glance, some of the functional concepts seem alien and overly complicated, and many beginner tutorials already confront the reader with terms from category theory. If somebody with an imperative background commits themselves to the functional paradigm, they usually have a thorough understanding of its benefits, and why (and when) the transition is worthwhile.

After having programmed almost exclusively in Java for eight months, I miss the convenience of the Scala language and its standard library. In Scala, everything fits together seamlessly, types can be composed and decomposed, there is no need to write boilerplate-ridden classes for simple data types or shoehorn data into unsafe, cumbersome collection types. Scala, I miss you, and I hope we will meet again one day.

Top comments (1)

Collapse
 
andyserrato profile image
Andy Serrato

Awesome πŸ‘

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.