Evolving Scala, Scalar conference, Warsaw, March 2025
- 1. Evolving Scala Martin Odersky with material from Haoyi Li Scalar 2025
- 2. Where Does Scala Stand Today? • The hype of the mid 2010’s has died down. • The language and ecosystem has been improving steadily. • The language is better understood and there’s more consensus how to apply it. • The space where Scala is has become crowded with old and new competitors moving in.
- 3. Where Scala ranked in 2014
- 4. Where Scala ranks in 2025
- 5. What has Changed? Technically, Scala is on stronger foundations than it was 10 years ago. Mature eco-system with particular niches in • Reactive systems (akka/pekko) • Effect systems (Cats Effect, ZIO) • Big data (Spark) • Hardware (Chisel) Alternative styles: • Scala toolkit • com.lihaoyi stack
- 6. Scala’s Value Proposition Scala was always a unifier Original goal: - unify functional and object-oriented programming But just as important: - Make the language at the same time safe and convenient. That was a success factor early on, when original adopters came from dynamic languages for the safe, but did not want to miss the convenience they were used to.
- 7. Safety and Convenience: Pick Two Large systems Object-Oriented Scala Functional Small scripts
- 8. Safety and Convenience: Pick Two Safety Object-Oriented Scala Functional Convenience
- 9. Going Forward • The programming landscape has not stood still. • Much of what used to be unique to Scala is now common: generics, type inference, lambdas, records, pattern matching are now standard. Scala must continue to innovate in both directions: Increasing safety without compromising convenience: features like explicit nulls, safe initialization, multiversal equality, opaque types aliases, dependent class types, capabilities. Increasing convenience without compromising safety: features like enums, named tuples, given/using, extension methods.
- 10. An Easier Language for Newcomers All advanced Scala users were newcomers at some point. All the big Scala projects you’ve heard about today started off as a bunch of newcomers: • Grad students trying out a language for their research project (Spark, Flink, Chisel) • Ruby or PHP folks trying out a language to improve the stability of their production systems (Twitter, Foursquare) • Java veterans wanting more flexibility, power, and rapid development (Kafka, Play)
- 11. Creating an On-Ramp The next big Scala projects will likely be started by newcomers picking up the language to solve a problem that nobody before had thought of solving. They will be smart, but they won’t be experts in advanced Scala features. They will know Python or JavaScript or Java because that’s what they learned in school. These are the people whom we need give an easy on-ramp to the language.
- 12. Creating an On-Ramp Practically this means: 1. Focus on code and documentation support for simpler, easier libraries like Scala toolkit or com.lihaoyi platform. 2. Align Scala syntax with other languages where it diverges unnecessarily. 3. Emphasize a lean program style. The goal must be that someone seeing plain Scala code gets the impression that this is 100% legible and natural. With Scala 3 we made great progress in this direction, and we should keep going.
- 13. Alternative: Why Not Go All-In on Framework X? • Go all in on Scala as a pure functional programming language? • Go all in on IO monads as the way to structure applications? IMO this would be short-sighted. Scala is amazingly versatile, from client to server to hardware design. Frameworks and styles come and go.
- 14. Why Not Freeze all New Features? Often heard request: Freeze all new features until tooling has caught up! Seems sensible but let’s take a closer look. What is “tooling”?
- 15. Tooling: Compiler Main effort of the whole team is to keep improving the compiler for correctness, robustness, speed, error messages. Research students are the ones that make sure your type checker behaves as expected and that performance regressions get fixed. They are not paid for that, but they do it anyway.
- 16. Tooling: IDEs These are done by different teams at Jetbrains and Virtuslab. The compiler team and Scala Center helps them where they can: - BSP protocol - Expression evaluation in the debugger - Presentation compiler support - Tooling summits.
- 17. Tooling: Build Tools • SBT has traditionally had a steep learning curve, but it is improving. • Scala CLI is a gamechanger for the getting started experience. • Alternative build tools such as Mill exist and are also getting traction. • And you can always use Maven or Gradle.
- 18. Tooling vs Evolution If we freeze feature development: • We lose contributors and contributions • Hence, Scala loses momentum • Hence, less funding for tooling • Hence, worse tooling than what we could get otherwise That said, we must always balance the benefits of a new feature with its conceptual and implementation cost. So far, Scala has been on the minimalist side of the spectrum. We intend to keep it that way.
- 19. Tooling: How You can Help For the compiler and IDEs: • Good bug reports and minimizations go a long way • Regular compiler and tooling sprees sprees get people up to speed. Financially: • Donations to Scala Center. • Get your company to become an advisory board member.
- 20. Language Evolution Guided by the SIP process Everyone can propose a SIP. Refined and intentionally slow processes: 1. 1st Step: Discuss on Scala Contributors 2. If feedback is positive submit a proposal 3. SIP committee discusses and decides on design 4. If design accepted, implement it as an experimental feature. 5. SIP committee decides again on final implementation. 6. If implementation is accepted, it will be added as a preview feature, typically in the next minor release. 7. This gives IDEs time to catch up before the feature ships as standard.
- 21. Recently approved SIPs • SIP 58: Named tuples (ships). • SIP 61: Unroll default arguments for binary compatibility. • SIP 62: Better Fors (ships). • SIP 64: Syntax improvements for context bounds and givens (ships). • SIP 68: Referenceable package objects.
- 23. Long Term Focus: Capabilities A language needs steady improvements. But it helps if it also has a long-term vision. For Scala, we bet on capabilities as the core of that vision. • But isn’t that an advanced feature? • In fact, it is the logical next step for Scala since it can make the interface between functional and imperative code safe and convenient.
- 24. The Dilemma of Mostly Functional Languages • Mutable vars (and other effects) are convenient. Used responsibly they make code cleaner and more performant. • But arbitrary side effects are not safe.
- 25. Scala Programmers like their Guardrails Dilemma: • Vars used responsibly make code cleaner and more performant. • But how do we ensure they are used responsibly, in particular in a heterogeneous team? • Code reviews? -- only go so far • Tests? -- likely would not have caught the problem Uneasy choice: convenient and fast but unsafe or safe but complex and slow?
- 26. Languages Should Encourage Good Code Ideally: A program that looks simple on the surface is also safe and predictable. But with effects, that’s not always the case. Using effects can make programs shorter but also harder to reason about. One answer is to use a staged architecture for effects.
- 27. Effect Systems Filesystem Errors Network State Transactions 1st stage program has direct access only to pure FP. All effects are handled by the monad(s). What computers can do What programs can do
- 28. One stage only Program can access all of machine But access is controlled by fine- grained capabilities Filesystem Errors Network State Transactions Resources Alternative: Capability-Based Architecture
- 29. Capabilities The (object-) capability model is dates from the 1960s when people first grappled with scaling software. • Capabilities are immutable values • Passed in method calls to code that needs them. Very influential in security. Most people agree it’s the right model to protect trusted components from untrusted ones. So why is it not ubiquitous today?
- 30. Problems with Capabilities 1. They are not that convenient: • Lots of parameters to pass around 2. They could also be safer: • Lifetimes or sharing are hard to enforce statically.
- 31. Better Capabilities Two ideas: • Passing capabilities implicitly makes them convenient • Tracking capabilities in types makes them safe. Scala 3 is uniquely positioned as a host language for capabilities because it has • Using clauses -- so capabilities can be passed without boilerplate • Path-dependent types -- so we can refer to capability parameters in types
- 32. Classes of Capabilities Capabilities are extremely versatile. They can model • Effects such io or async • Advanced control constructs via labels • Mutations to specific variables or regions • Permissions to execute an action or get access to data • ... They subsume • effect systems • ownership types • borrow checking • information flow systems • ...
- 33. Classes of Capabilities Capabilities are extremely versatile. They can model • Effects such io or async • Advanced control constructs via labels • Mutations to specific variables or regions • Permissions to execute an action or get access to data • ... They subsume • effect systems • ownership types • borrow checking • information flow systems • ...
- 34. Capabilities for Mutation (A glimpse of the future) Here’s a method for matrix multiply: Questions: • What is input, and what is output? • What arguments can be shared and which must be unique?
- 35. Capabilities for Mutation With the capability system we have working in the lab, you would write: The ^ means: “Can be modified” (effect) The ^ also means: “Does not share with with anything else that can be accessed” (separation)
- 36. Summary • Languages need to be (carefully) evolved, or they lose relevance. • The main value proposition of Scala is to be both safe and convenient. • This guides the evolution of the language. • Looking forward to discuss this both here and at the next major Scala event:
Editor's Notes
- #1: Hello