Press enter or click to view image in full size
It was 2016, and I was convinced I had found the future of programming.
I remember the exact moment. I was refactoring a gnarly Java service — hundreds of lines of boilerplate, null checks nested three levels deep, and a for loop that made my eyes water. Then a colleague showed me the Scala equivalent. Twenty lines. Pattern matching. Immutable data structures. It was like watching someone solve a Rubik's cube in six moves while I'd been peeling off the stickers.
I was hooked.
For the next three years, Scala became my language of choice. Play Framework for web apps. Akka for concurrency. The elegance of map, flatMap, and fold replacing clunky imperative code. I preached the gospel of functional programming to anyone who would listen.
Then, slowly, the cracks appeared.
New team members took months to become productive. Code reviews turned into graduate-level seminars on category theory. And when I tried to hire Scala developers in 2018, I might as well have been searching for unicorns.
By 2019, I had quietly moved on. And I wasn’t alone.
The Golden Era: When Scala Was Going to Change Everything
To understand Scala’s decline, you need to understand its intoxicating promise.
Created by Martin Odersky at EPFL in 2004, Scala was designed to be a “scalable language” — one that could grow with your needs, from simple scripts to massive distributed systems. It ran on the JVM, which meant instant access to Java’s vast ecosystem. But unlike Java, Scala embraced both object-oriented and functional programming paradigms.
The timing was perfect. By 2010, the tech industry was drowning in Java’s verbosity. Developers wanted expressiveness. They wanted elegance. They wanted to write less code that did more.
Twitter’s adoption was the inflection point.
In 2009, Twitter was struggling. Their Ruby on Rails backend couldn’t handle the “fail whale” scale of their growth. They needed something that could handle real-time messaging at massive scale. They chose Scala, and it worked. The engineering team built Finagle, their RPC system, and open-sourced a treasure trove of Scala libraries.
Suddenly, Scala had credibility. If Twitter could handle 500 million tweets per day with Scala, maybe your startup could too.
LinkedIn followed. So did Netflix, Airbnb, and dozens of other high-profile companies. Apache Spark, the big data framework that would come to dominate analytics, was written in Scala. For a few years there, learning Scala felt like learning a superpower.
Press enter or click to view image in full size
Between 2013 and 2016, I watched Scala climb the TIOBE index. Job postings multiplied. Conferences sold out. The future belonged to functional programming, and Scala was leading the charge.
So what went wrong?
The Complexity Tax: When Elegance Becomes a Burden
Here’s a confession: I never fully understood implicits.
I used them. I copied patterns from Stack Overflow. I knew they made certain kinds of dependency injection elegant. But if you’d asked me to explain exactly what was happening when the compiler resolved an implicit parameter chain three levels deep? I’d have mumbled something about type classes and changed the subject.
And I was the Scala advocate on my team.
Scala’s greatest strength — its expressiveness — became its greatest weakness. The language gave you so many ways to do things that codebases started to diverge into incompatible dialects. One team’s Scala looked like “better Java.” Another team’s looked like Haskell cosplay.
The learning curve was brutal. According to a 2024 analysis by Baeldung, Scala remains one of the most difficult mainstream languages to learn. The mix of functional and object-oriented paradigms, the complex type system, and features like implicits, macros, and higher-kinded types created a mountain that many developers simply didn’t want to climb.
I watched talented Java developers — people with a decade of experience — struggle for months to become productive in Scala. Some never did. They’d write Java-in-Scala, missing the functional patterns entirely, or they’d over-engineer everything with monads and type-level programming that nobody else could read.
Hiring became a nightmare. When you filter for “Scala developers,” your candidate pool shrinks dramatically. When you filter for “Scala developers who write idiomatic, maintainable code,” it nearly disappears. Companies started paying 30–40% premiums for Scala talent, and even then, positions would stay open for months.
// The kind of code that made me fall in love with Scala
val result = users
.filter(_.isActive)
.flatMap(_.orders)
.map(_.total)
.sum// The kind of code that made me fall out of love
implicit def enrichedFuture[A](f: Future[A])(implicit ec: ExecutionContext): EnrichedFuture[A] =
new EnrichedFuture(f)class EnrichedFuture[A](f: Future[A])(implicit ec: ExecutionContext) {
def |>[B](g: A => Future[B]): Future[B] = f.flatMap(g)
def <*>[B](fb: Future[B]): Future[(A, B)] = for { a <- f; b <- fb } yield (a, b)
}
The first snippet is beautiful. The second? That’s the kind of code I’d find in production, written by someone who’d read too many blog posts about applicative functors. Debugging it felt like archaeology.
The Kotlin Knockout: Death by a Thousand Paper Cuts
Then came Kotlin.
JetBrains released Kotlin 1.0 in 2016. By 2017, Google had announced it as an official language for Android development. And suddenly, Scala had a competitor that offered 80% of the benefits with 20% of the complexity.
Kotlin was pragmatic. It didn’t try to be a research language. It didn’t attempt to unify every programming paradigm. It just took the pain points of Java — null pointer exceptions, verbosity, lack of lambdas (pre-Java 8) — and fixed them with straightforward solutions.
The syntax was familiar. Java developers could be productive in Kotlin within days, not months. The tooling was excellent (JetBrains made the language and the IDE). And it compiled fast — significantly faster than Scala.
Here’s what killed me: the arguments I’d used to convince teams to adopt Scala in 2015 worked even better for Kotlin in 2018. Null safety? Kotlin has it, without the complexity. Concise syntax? Check. Java interop? Better than Scala’s, actually. Functional programming features? Enough for practical use, without the academic overhead.
“Kotlin’s learning curve is much smaller, especially for those coming from Java, because it has fewer functional programming principles and tries to look as familiar as possible.” — Baeldung
One by one, I watched teams that might have chosen Scala choose Kotlin instead. The Android ecosystem went Kotlin-first. Backend services started migrating. By 2020, Kotlin had eaten Scala’s lunch in general-purpose JVM development.
The Web Development Retreat
Remember when I mentioned Play Framework?
In 2015, Play was a genuinely compelling choice for web development. It was reactive, performant, and felt modern compared to Spring’s XML configuration hell. I built several production applications with it, and they ran beautifully.
But Play had a problem: it was competing against an army.
Node.js exploded. Python’s Django and FastAPI got better. Go became the darling of microservices. Even Java’s Spring Boot evolved into something actually pleasant to use. And Kotlin started offering its own web frameworks — Ktor, Spring Boot with Kotlin — that were easier to staff and maintain.
The Play Framework community still exists, but it’s a shadow of its former self. The conversation shifted from “should we use Play?” to “how do we migrate off Play?”
For web development specifically, Scala lost the argument. Not because it couldn’t do the job — it absolutely could — but because the complexity tax wasn’t worth paying when simpler alternatives existed.
Where Scala Still Wins: The Big Data and Finance Strongholds
Here’s the thing: Scala isn’t dead. It’s just… specialized.
As of 2025, Scala sits around #27–33 on the TIOBE index, depending on the month. The 2024 Stack Overflow survey shows about 2.6% of developers using Scala extensively. That translates to roughly 500,000 active developers worldwide — not massive, but not insignificant either.
And in certain domains, Scala remains dominant.
Big Data: Apache Spark, written in Scala, is still the industry standard for large-scale data processing. If you’re doing serious analytics work, you’re probably writing Spark jobs, which means you’re probably writing Scala. Yes, you can use PySpark, but you’ll hit performance ceilings and miss features that only the native Scala API provides.
Financial Services: According to industry analysis, demand for Scala in finance “has absolutely exploded.” J.P. Morgan, Goldman Sachs, Morgan Stanley, Barclays — the big investment banks have significant Scala codebases. When you need to process millions of transactions with microsecond latency and provable correctness, Scala’s type system becomes an asset rather than a burden.
Streaming and Event Processing: Kafka (written in Scala), Akka Streams, and similar tools remain best-in-class for high-throughput event processing. The companies that need this capability are willing to pay the complexity tax.
Press enter or click to view image in full size
The pattern is clear: Scala retreated to domains where its strengths — the type system, the performance, the functional programming paradigms — provide genuine competitive advantages that justify the costs.
The Scala 3 Question: Renaissance or Last Gasp?
Scala 3 (formerly known as Dotty) represents the most significant overhaul in the language’s history. Released in 2021, it cleaned up many of Scala 2’s warts: implicits were replaced with a clearer given/using syntax, the macro system was rebuilt, and numerous syntactic improvements made the language more approachable.
The reaction has been… mixed.
On one hand, developers who’ve migrated report that Scala 3 is genuinely nicer to write. The code is cleaner, the error messages are better, and many of the footguns have been removed.
On the other hand, migration has been painful. Some teams report having to modify thousands of lines of code, fighting merge conflicts while the rest of the organization continues shipping features. Libraries that relied on Scala 2 macros needed complete rewrites. And Apache Spark — Scala’s killer app — took years to fully support Scala 3.
The community is cautiously optimistic. A 2024 VirtusLab survey found that 93% of Scala developers either love or like the language. But whether Scala 3 can attract new developers, rather than just retaining existing ones, remains an open question.
What Scala Taught Me (And Why I Don’t Regret It)
Looking back at my Scala years, I don’t regret a moment.
Yes, the language eventually became impractical for the general-purpose work I was doing. Yes, I moved on to more pragmatic choices. But Scala fundamentally changed how I think about programming.
It taught me about immutability — not as a constraint, but as a tool for reasoning about code. It taught me about composition over inheritance, about expressing domain logic through types, about the power of treating computation as data transformation rather than state mutation.
When I write Python now, I reach for map and filter instinctively. When I design APIs, I think about making illegal states unrepresentable. When I review code, I look for mutation and side effects as red flags.
Scala was my gateway to functional programming, and functional programming made me a better developer. The language was just too pure for its own good.
The Verdict: A Cautionary Tale About Complexity
Scala’s trajectory offers a lesson for the entire industry: power without accessibility is a dead end.
The language could do incredible things. It still can. But it asked too much of ordinary developers, teams, and organizations. While Scala’s designers were perfecting their type system, Kotlin’s designers were watching developers struggle and asking, “How do we make this easier?”
Today, Scala occupies a respected but narrow niche. It’s the language of choice for data engineers, fintech specialists, and a devoted community of functional programming enthusiasts. For the rest of us — the pragmatists building CRUD apps and REST APIs — simpler tools won.
I still think about Scala sometimes. I see a gnarly piece of Java code and remember how elegantly a for comprehension could express the same logic. I feel a twinge of nostalgia for those 2016 days when functional programming felt like a revolution and Scala was its standard-bearer.
Then I open my Kotlin project, get my work done in half the time, and remember why I moved on.
Scala didn’t fail because it was bad. It failed to achieve mainstream adoption because it was too good — too powerful, too expressive, too demanding. In programming, as in life, sometimes good enough beats perfect.
The language that promised to scale with your needs ultimately couldn’t scale with the industry’s patience.
Sources
- Twitter on Scala — Artima
- Kotlin vs Scala — Baeldung
- Scala vs Kotlin — Slant
- Play Framework Discussion — Lightbend
- TIOBE Index
- Scala 3 Migration — VirtusLab
- Scala 3 Migration Report — Pierre Ricadat
- Scala 3 Tech Report — SoftwareMill
- Scala Development Trends 2025 — Scala Teams
- The Death of Hype: What’s Next for Scala — Li Haoyi