My Experience with Scala: 6 months of Scala

I started a new job in November 2019, about 6 months ago.

In my previous jobs, I had been an application developer and an application architect. Apart from a few quarters, where I worked on Adobe Experience Manager, and Salesforce with Vlocity, I have primarily been a Java+Spring developer over the past decade.

During onboarding, I was to work with a team that was using Scala as its primary language to process hundreds of thousands to multiple million messages per day.

I had never used Scala, and had to make a decision, whether to give it a try, or whether to continue with the team I had interviewed.

I thought I will give it a month and decide what to do. Thus, began my tryst with Scala. I am writing this with an expectation that I can track my progress in another 6 months or a year, and see if I am still writing Scala.

The team recommended I go through Essential Scala and join a weekly Scala Learners community that a few of the colleagues were going through.

Unfortunately for me, I do not learn well in communal environments, and was not really willing to dive into a book unless I knew how I could leverage my existing knowledge to figure out what I needed to unlearn and learn.

I started with the Scala for Java Developers page on Scala Lang.

I liked how the page provided information, so started to explore more on the same site.

The next stop was Getting Started on the same site.

This helped me setup my system for hands-on, and I went through the Tour of Scala guide, also on the same site.

Going through this gave me enough confidence to start looking at books I could read.

The challenge with this was that I got nearly as many recommendations as there were people on the team. My takeaway was that I need to figure out one or two books that will suit me.

Based on what I felt after writing the few snippets to get familiar with Scala, I wanted to understand functional programming better, and I wanted to become productive quick enough. So, my choices were:

  1. Functional Programming in Scala
  2. Scala for the Impatient

I went through the 1st book in a weekend. I started through the 2nd book, but only skimmed it as I thought I had already gained what I needed to know in between the scala-lang pages and the functional programming book.

After a few sprints of productive work beginning January, I realized I could just continue working in Scala and pickup Java if I had to find a new project or a job in a week or two. So I started looking for a more robust foundation, and came across a Functional Programming in Scala Specialization on Coursera that has some courses delivered by Mr. Odersky himself. I thought it would be helpful to get a sense of what the author actually meant when creating the language.

So, I started the course, but it soon became laborious. The lectures delivered by Mr. Odersky were great, but the exercises were dissonant from the lecture. It felt the course needed me to think as well research outside the course material itself which I was not prepared to do. After all, coursera courses are pretty expensive and I had hoped to be spoon-fed. Similar to what I had found on udemy for AWS-SAA certifications (yes, I am AWS-SAA!).

Anyway, this was March, and I think this is all the “textbook” learning I have done so far. However, I have been diving into production code every day, at least 6-7 hours, so I have been reading a lot of Scala code.

So, now to the main intent of this article, here are my observations so far in the last 6 months.

  1. You either love the language, or you hate it.
  2. I love writing Scala code, but I hate reading what others have written. The language is extremely hard to read.
  3. Developers can go overboard with overloading symbols. This too makes the code hard to follow.
  4. The language has poor inline docs. This essentially fosters the belief among Scala developers that the code is indeed easy to follow, so they don’t need to document what their method does/intends to do.
  5. Implicits are hard to understand initially and can cause unexpected, silent failures. E.g. using implicit json4s serializer will fail to serialize a case class that has enums. Well, it does not fail as much as it just serializes what it can, and silently + implicitly, ignores enums. So, you need to “remember” to do stuff (e.g. update the serializer if you update your case class), which is always hard to maintain in code where the actual transfer of message is typically (and correctly) isolated from where the message is constructed.
  6. We use Akka Streams heavily, and I find the actor model rather enjoyable for concurrent programming. We use the Scala DSL, but internet tells me many teams do use its Java DSL too. In the last 6 months, I have not seen a single bug due to thread/concurrency issues. My vote is a plus for Scala if you want to use Akka.
  7. The language is very powerful, so if you do plan to use it, you must create some standardization practices. If not, the 5 different ways one can solve the same problem will become an expensive nightmare for the team that is going to look at your code in 5 years.
  8. The tooling is not very powerful. I use IntelliJ and it frequently shows errors in the IDE even when the code compiles and builds fine via the command line. Also, because it is the compiler where all the implicit magic happens, Scala can be painfully slow to compile.
  9. To round off, at this time, I feel aligning with Scala implies you should be prepared to spend a lot of money to maintain your projects (as compared to using plain old Java with some framework that suits your needs).
I hope to write a follow-up if I continue working on the same project for the next 6 months.