Why I am moving away from Scala

I have been a Scala developer for almost ten years. It was a fascinating journey, marked by exciting projects and numerous meetings with talented software engineers. However, I decided to step out of Scala, and this post is about why I chose to do so.

How I got into Scala

Like many other Scala developers, I came from the Java world. At my first job as a backend engineer, I got a project written in Play Framework. This framework is written in Scala, but you can also use it for Java development. When you read the documentation for Play, it gives you code examples for both Java and Scala, and the Scala code looked much cleaner and expressive. It was free from cumbersome, duplicated Java keywords, and the Scala examples also had fewer lines of code. So I got curious about the language. My curiosity was also driven by the fact that Scala was still in hype at that time. The language had a reputation as the next Java, eventually replacing its old, verbose cousin.

I started to learn Scala by completing an online course from Lausanne’s tech university (EPFL), where the language originates. Shortly after, I changed jobs, got a position as a Scala developer, and since then, I’ve worked on many different projects with a Scala backend. I was happy where I was. The projects were interesting and challenging. But more importantly, all the colleagues, the fellow Scala developers, were bright engineers with whom it was a pleasure to work.

Nevertheless, after some years, my attitude to the language has changed. Several problems in the language’s ecosystem led me and other developers to abandon Scala. The primary trigger was the release of Scala 3, or to be more concrete, issues related to it. But apart from this, there are also other problems with the language.

Scala 3 adaptation issues

Scala 3 was released in 2021. It was a long-desired upgrade full of tasty features, and every Scala developer couldn’t wait to try them. It is already 2025, but the Scala community has not fully switched to version 3. Moreover, most projects I know still use Scala 2. The reason is that the new major version of the language has several significant issues that hinder its adoption.

First of all, there is no backward compatibility, which makes it challenging to upgrade the existing applications. The lack of backward compatibility was not a big surprise. EPFL made it clear long before the official release. However, EPFL did not make a big deal of it, claiming that “since Scala is statically typed, the upgrade will be much easier than the upgrade from Python 2 to 3, for instance”. The reality is that it is not easy, and you’ll need several sprints to upgrade an average-sized codebase. It is a very long time for a tech debt story that does not bring much value. Yes, I wrote before that the new features looked appealing. The third version finally got the union types, proper enums, nice syntactic sugar improvements, less confusing implicits, and many other things. But you could write workable and maintainable software before, using Scala 2, without all these syntax improvements.

Another problem with the upgrade is that many popular Scala libraries started to support the third version very late or have not started it at all yet. So even if you managed to upgrade your application, you still have to use dependencies from the previous major version of the language, with all the risks of compatibility. You can understand the maintainers of the libraries very well: It’s highly annoying to support two parallel versions of a language. Many of them lacked a compelling reason to migrate to Scala 3, as most of their users remained on the second version.

I also noticed an opposite trend recently, that some library maintainers started to provide upgrades only for Scala 3. If you haven’t upgraded your codebase yet, you’ll stop receiving upgrades for the dependencies, including security patches. It gives you a more valid reason for the upgrade. Still, again, it is not a quick task, especially in the current economic situation when companies are under financial pressure and teams are downsized. Additionally, you may still be blocked by dependencies that do not support Scala 3 yet.

Poor Scala 3 tooling support

Let’s assume you got lucky enough to upgrade your old Scala 2 codebase. Or you even got a green light for building a brand new application in Scala 3. Do not celebrate it too much! After more than four years since the release, Scala 3 still has a lot of issues with tooling, which do not make the language fully production-ready.

For instance, while working on a software project, I prefer to rely on CI/CD pipelines that allow deploying the application only if certain checks are passed. The pipelines run unit tests and other types of tests to validate the application. Then the pipelines run a test coverage check to make sure the code has sufficient automatic testing. Additionally, the pipelines can run checks for the code itself, such as static analysis, to catch pieces of code that are semantically correct but not written according to best practices. All these checks help you to build a reliable software and prevent many nasty issues in production. Unfortunately, the tooling for the test coverage and code validation has horrible support for Scala 3.

You can use the test coverage plugin in some way. However, there are still plenty of bugs, such as false positives for lines of code that are executed in the unit tests. Besides, the plugin still does not have all the features that were available for Scala 2. Anyway, it is a tremendous progress compared to the situation at the beginning of the year, when the plugin gave you completely wrong calculations of the test coverage. The situation is significantly better than with the static analysis plugin, which I couldn’t get to work. It runs, but it ignores all the suspicious uses of code, always giving you the green light. Remember, it is a situation four years after the release of the language!

Another complaint goes to the IDE support. In IntelliJ, the Scala 3 coding experience is terrible. Sometimes, you need to wait for a minute to get the code completion hints. Often, the error highlighting stops working, so you have to start rebuilding the project manually. It is not as if there’s no good IDE support at all. Metals, the Scala LSP server, provides you with a better Scala development experience now, and it is constantly getting improved. However, it is highly disappointing and strange that the most popular IDE in the Scala world still lacks proper language support.

To make it worse, even Sbt, the primary Scala building tool, is buggy while working with the third version. It is not always successful in building and running an application. The most annoying thing for me and my colleagues is running the unit tests. Only every fifth attempt is successful. For all the rest, you get annoying “Class not found” exceptions, every time for a random different class.

At the same time, Scala 3 still inherits annoying issues from the past. For instance, you still have the SemVer vs PVP conflict problem or the forward compatibility issues. All these problems make the development experience terrible. And it is deeply concerning that the third version still has so many issues several years after its release.

Small but fragmented ecosystem

The Scala ecosystem is relatively small because the language is not among the top-tier languages. But here’s a fun fact: there is no dominating framework or library. For instance, when discussing backend development in Java, it typically refers to building an application using Spring. In Python, Django heavily dominates in the niche of web development. You cannot imagine Ruby without Ruby on Rails. However, it is hard to recall such examples in Scala, except for Apache Spark. But the latter one focuses more on data engineering than software development. For the other areas of Scala’s application, we lack a de facto standardized framework or library.

This is particularly true for backend development, the central niche of the language. Here we have only the top tier consisting of several names: Akka (nowadays also Pekko, after the Akka licence change), Play Framework, ZIO, Lagom, Cats, and so on. We can find similar examples in smaller application areas, where you need a library for solving a specific issue. You will get again a “great” choice of dozens of concurrent components, without a prominent leader. The classic example is the thousand JSON serialization/deserialization libraries, which became a target of jokes in the Scala community. So it seems that every Scala developer has written their own solution for processing JSON at some point in time. And if you work with an old and large Scala codebase, you will likely find a couple of different JSON libraries there, added by other developers at different stages of the project, or introduced as a transitive dependency.

Of course, the great variety and diversity are highly beneficial in all areas of our lives. Monocultures are damaging not only in the natural ecosystems but also in IT. However, the Scala ecosystem has at least a couple of adverse side effects due to its high number of concurrent frameworks and libraries.

First of all, the higher number of concurrent projects results in a lower number of users per project, which in turn leads to fewer contributors and maintainers. And take into account that Scala is not among the most popular languages! So the number of developers here is already small. As a result, even popular Scala libraries are maintained poorly compared to other languages. Bugs can stay unfixed there for a very long time. Adaptation to new language versions is very slow (as I wrote above, it is not such an easy task in the Scala ecosystem). Finally, there is a very high chance of a project becoming abandoned. The last example is the most frustrating. Occasionally, during a dependency update, you may notice that a library has not had any new releases for a while, and the latest changes in the repository are dated a couple of years ago. Then you have a tough choice: either find an alternative library, refactor your codebase, or hope that there will be no serious vulnerabilities in the dependency.

The second problem is that the high number of frameworks and libraries makes the Scala ecosystem highly complex and challenging to navigate. The language itself is not beginner-friendly. But in addition, you should also be familiar with a large number of Scala repositories and components to be able to work on different projects. If you are a newcomer, it is easy to get lost in all these alternative solutions. It is hard to figure out which frameworks you need to learn first, which are essential for the industry, which are not, and what the standard approach is to build an application in general. So the Scala ecosystem’s fragmentation not only makes the life of existing Scala programmers harder, but it also makes the language less attractive for junior developers.

The language is dying

In 2018, I attended a Scala conference in Berlin. During the round table sessions about Scala’s future, you could already hear the cynical statements that “the language is not dead yet”. It was already clear that Scala would not replace Java, and the language was becoming a niche tool. The Scala’s future did not seem as bright anymore, as it had seemed before. So it is not surprising that the optimism and the enthusiasm were already low at that time.

Since then, the situation has been getting only worse. You can see the decay of Scala in all the popular rankings and surveys. For instance, the Stack Overflow survey shows a clear downward trend. From 2018, the year of the conference, to the current 2025, the popularity fell from 4.4% to 2.6%. Now, Scala ranks below Elixir, a quite esoteric and narrow-specialized language. It is also amusing that Groovy, with 4.8%, is several lines above Scala, given the urban legend that Groovy’s creator acknowledged Scala’s superiority and abandoned further development of the language.

Despite the decline, there were still plenty of Scala projects, at least in the Netherlands, where I live. However, over the last few years, all these projects have been legacy systems dating back to the golden age of Scala, when the language was trendy and developers were curious about it. I haven’t heard about any new Scala projects starting for a while. The conservative cohort of developers continues to use Java + Spring for the backend development. Other programmers try water with Rust or Go. We also have Kotlin, which allows using Spring Boot for backend development without Java’s boilerplate. You can even see Typescript or Python as backend languages, mainly in the startup area. So the developers are losing interest in Scala. The Stack Overflow surveys also confirm it. In 2023, 52.3% of the respondents wanted to use Scala. In 2025, the number is 39.4%, which is comparable to that of PHP, 38.9%, and below good old Ada with 41.2%.

I see the following reason for this negative trend. The language remains complex, making it less accessible to newcomers. But at the same time, you would not get a sexy greenfield project as a Scala developer. Most likely, you will get a relic legacy system with a pile of tech debt gathered by a couple of generations of programmers before you. It is not the most exciting prospect, especially for the junior developers. Considering this and all the issues listed in the previous parts, it’s not surprising that Scala is going downhill.

Moving forward

To conclude, the language has numerous annoying issues. First of all, the unsuccessful release of Scala 3 introduced numerous problems in supporting existing projects, as it was not yet production-ready. The Scala ecosystem faces challenges due to its high number of concurrent libraries and lack of consolidation. Finally, it is getting harder and harder to jump into an interesting Scala project because the language is losing its popularity.

Unfortunately, it is time to move on. I still love the language. I enjoy how expressive Scala is, how easy it is to describe the application’s logic thanks to functional programming. But more importantly, you are always surrounded by brilliant people if you work on a Scala project. The language attracted excellent developers, I was never the smartest person in the room. Sadly, the problems have managed to outweigh the benefits, and Scala is now in a dead spiral.

About which language to pick up next, I have a couple of candidates. First of all, Kotlin is a popular choice for switching among Scala developers. It is also a JVM language that stands somewhere between Java and Scala. It lacks the support of advanced functional programming magic, compared to Scala. But at the same time, it is more expressive than Java and has a nice mechanism for null-safety.

Then I am also thinking about Go. It is the opposite of the paradigm perspective from Scala, lacking functional programming, but instead employing the old-school procedural style with some object-oriented programming. It has a reputation for being a simple language. It is indeed an easy-to-approach language, but not only from a syntax perspective. It has many nice features that make a developer’s life much easier. Go has a rich set of out-of-the-box tools and libraries, and at the same time, it has a much broader and stronger ecosystem. I also appreciate that the backward compatibility principle is a cornerstone in the Go world.

Time will tell where I will end up next. But I know for sure I have to move on from Scala and change ecosystems for another time in my career.