Scala returning to its origins: A tale of 4 chapters

This is my personal review of a talk given by Martin Odersky at Scalar Conf 2025. If you would like to watch Martin’s talk, here you have it.

Evolving Scala by Martin Odersky

1. The Retrospective

When Scala emerged as a new programming language, it offered two main components in its value proposition. On one hand, it provided a unified paradigm that harmoniously merged object-oriented and functional programming. On the other, it was both safe and convenient. This appeal attracted many talented engineers and bright students, leading to innovations like Twitter, Akka, Spark, Flink, and Play, among others.

The initial excitement that once propelled the language into the limelight during the mid-2010s has diminished over the last 15 years. Various business decisions have altered its public perception. For example, events such as Twitter’s rebranding to X, and PySpark’s rise in the data engineering realm over Spark have all contributed to this decline.

Nevertheless, amid these challenges, the language and its ecosystem have matured remarkably, with a community that has rediscovered its original appeal—a multi-paradigm language that is both safe and convenient. Despite fierce competition from established languages like Java (which adopted features once unique to Scala) and emerging ones such as Kotlin and Rust, Scala has maintained its competitive edge over the last two decades.

2. The Long Journey Back to the Origins

Since 2020, the community has embarked on a bold mission to reinvent the language. While Scala 2 was always safe, it had evolved into something many found increasingly inconvenient. I have read many critics who argued that Scala resembled Haskell too closely, making it difficult to attract sufficient engineering talent and posing challenges for newcomers—mastering intricate concepts like category theory and effect systems is no small feat.

In my opinion, sbt (Simple Build Tool) is a perfect example of this evolution. Initially a very easy-to-use and accessible build tool, sbt has evolved into an extremely powerful utility that is no longer simple. Yet, driven by deep affection for the language, the community set a goal to simplify what had become onerous and reaffirm Scala’s commitment to safety and ease of use.

Over the past five years, debates over Scala’s programming paradigms—whether functional, declarative, imperative, or object-oriented—have gradually given way to a collective focus on its core identity. As long as Scala delivers safety and convenience, the underlying paradigm takes a back seat. This clarity of vision culminated in the birth of a new language variant: dotty. A bridge was then built linking the old and the new, ushering in Scala 3 four years ago.

3. Regaining What Should Have Never Been Lost

Scala 3 focuses on enhancing both safety and convenience. It introduces features like opaque types for improved type safety, along with enums, named tuples, and extension methods that boost usability without compromising security. While the language remains expressive and powerful, these refinements aim to make Scala more accessible and manageable for developers.

Martin Odersky has noted that the complexities of the language can discourage new users, emphasizing the need for simpler learning resources and libraries. To attract fresh talent, the community has aligned Scala 3’s syntax with that of popular languages like Python—eliminating unnecessary syntactic clutter—thus easing the transition for newcomers.

Robust tooling—such as compiler improvements, a refined command-line interface (ScalaCLI), and enhanced IDE support—is fundamental to Scala 3’s evolution. Continuous improvements in compiler reliability and IDE support are being prioritized, with community feedback playing a crucial role. The Scala Improvement Process (SIP) has been carefully crafted to balance the introduction of innovative features with the critical stability of tooling and libraries.

4. The Future of Scala

Looking ahead, Scala 3 envisions a future centered on capabilities that offer a secure and convenient way to manage side effects in programming. In his talks, Martin Odersky highlights the potential for adopting a capabilities-based architecture, which will enhance both functional and imperative programming styles without sacrificing safety or convenience. Integrating capabilities into the language type system represents a significant milestone, ensuring that the language remains versatile and relevant in a rapidly evolving technological landscape.

My Personal Take

I have been using Scala 3 professionally for the last two years and I like it immensely. I must admit that it took some time for the tooling to catch up, but right now it works exactly as I need it to. Many aspects that made Scala 2 challenging—such as implicits, metaprogramming, and type classes—have been redesigned. To make the language more ergonomic, new reserved words have been introduced. For example, the concept of ‘implicit’ has been split into four keywords: ‘given’, ‘using’, ‘extension’, and ‘Conversion’. Metaprogramming has become more accessible for junior engineers, with parts of it now integrated into the language using keywords like ‘opaque’ and ‘inline’. Another feature I enjoy is named tuples, which are extremely handy for handling intermediate steps in complex data manipulation. For me, capabilities are the great promise that will free the language from the constraints imposed by effect systems.