Scala lets us write beautifully simple code. It incurs very low boilerplate and does not restrict expression in arbitrary ways. Scala itself is also quite a simple language, with few constructs that compose well. On the other hand, Scala is often described as difficult. I believe this criticism is not so much directed at the language itself but at certain libraries, frameworks and applications written in Scala. In my talk I want to raise this problem, and start a discussion how the Scala ecosystem can do better.

Today's large-scale algorithms, especially recommendation systems, play a major role in the spread of disinformation and hate speech. Yet, they are increasingly opaque, despite repeated scandals in big tech companies. In this talk, after underlining the danger they now represent for national security and global peace, I will present Tournesol, an open-source AGPL platform to collaboratively design a public utility content recommendation algorithm. I will stress in particular the mechanisms that were designed to secure the platform. I will then conclude by stressing the urgent importance of security, especially in the current geopolitical context.

Closures, or lambda expressions, are an essential language feature to work productively with popular data processing engines like Apache Spark and Flink, and they enable functional programming (FP), a style of programming that is gaining popularity for composable programming with effects, among others. However, more and more use cases in parallel and distributed programming are testing the limits of the flexibility of closures. For example, the requirement for closures to be serializable is a common source of errors when developing data processing or streaming applications. In a concurrent setting, for example, when programming with futures and promises, closures must be used with great care in order to prevent safety hazards like race conditions. In this talk you will learn how to spot potentially unsafe code using closures, how to write safer closure-using code, and how to use newly developed library components to increase the flexibility and safety of closures in Scala.

This talk would address newcomers and seasoned Scala developers and will show new ways to explore and enjoy our language.

When testing Scala language it’s almost impossible to test all corner cases and combinations of input - it’s simply too flexible and complex. Even with thousands of tests, eventually, some users would be able to break it. In such a case, how the Scala maintainers can detect defects in the compiler early and limit the number of bugs? If they only had some almost infinite amount of test cases… Wait a minute, from the compiler perspective, each Scala source file is a complete test case - they’re just waiting to be used!

Scala 3 Community Build is a tool used by the compiler team to test new versions of Scala against open-source libraries. During the talk, we will discuss how it is used to detect regressions in the compiler, and how it is managing the builds to avoid deadlocks and cycles between library dependencies.

“Fetchless” is a total reinvention of the famous Scala “Fetch” library from 47 Degrees. Like “Fetch”, “Fetchless” helps users parallelize, cache, and batch multiple requests together from multiple sources to make your programs faster. This new version is redesigned from the ground-up to be more flexible and familiar to modern Scala users, while also being over an order of magnitude faster in worst-case scenarios. The new multi-layered design allows you to have as little or as much control over individual requests as you’d like, such as adding your own functionality around the edges or even opting out of laziness or deduplication entirely to see massive performance gains. “Fetchless” also supports data streaming with FS2, debug logging, and comes with multiple integrations for popular Scala libraries out of the box.

In this presentation, I’ll go through the skeleton we use while creating new web applications in Scala/Scala.js, explaining the foundations and the architecture for it. Show casing that is can be very practical to create Scala/Scala.js web applications.

Our skeleton tries to stick to practical patterns, adopting pure functional programming when it makes sense, as well as being pragmatic while writing automated tests.

If you have ever wondered how we can onboard juniors to the Scala/Scala.js ecosystem, I have wonderful results with this skeleton.

Even if you do not use the skeleton, there are very good parts from it that you can likely adopt in your existing project.

On a growing number of campuses, data science programs offer introductory courses that include a non-trivial amount of programming. The content of such courses overlaps that of traditional computer science introductory courses, but neither course subsumes the other. This talk argues that a common introductory course that covers both data science and data structures supports students and provides curricular flexibility, while also bringing social impacts of computing into the early curriculum. We'll discuss both the design and implementation of such a course, with particular focus on programming language features that support it.

In Scala 3, you can do more with types by the virtue of match types and type-level operations, which increase the design space for compile-time verification. For example, operations for type-level arithmetic are available which can be used to verify the correct dimensionality of matrices in machine learning projects.

In object oriented languages one can compare instances of objects either by their identity or by inspecting their internal structure and looking at the values of their members. The Scala compiler can analogically compare types using two different strategies called nominal and structural typing respectively.

Even though nominal typing is used most of the time to guarantee type safety of Scala programs there are situations when it might be too constraining and decrease developers’ efficiency. In some cases this might even lead programmers to falling back to manual type casts or accessing members of a data type by their labels using runtime strings even though they’re known at compile time. Luckily for Scala coders trapped between Scylla and Charybdis, structural typing comes to the rescue as a decent compromise between these two extremes.

I will open my talk by showing the differences between nominal and structural typing and examining their relation to duck typing in the context of a statically typed language like Scala. I will also explain the role of type refinements in Scala’s type system.

Next, I will introduce Scala 3’s Selectable trait and its older sibling Dynamic. I will delineate how they’re handled by the compiler and how they can be composed with other features of Scala, including its new metaprogramming API.

Concludingly, I will demonstrate some real world use cases where the mentioned mechanisms can be used to make your code concise and expressive, yet type-safe. I will also mention some situations where you should hold your horses and consider some alternative solutions.

What constitutes a healthy community? How do we get there and who needs to participate to make it a reality? Where does Scala community stand now? And how does Scala Center's "Scala governance project" fit in all of this?

While exploring these questions, the authors encourage attendees to take action and join the movement, taking away three points

• It is possible to foster a healthy Scala community
• Scala Center is investing in community building
• Success requires individual community member’s engagement

Initiated by VirtusLab in 2021, Scala CLI aims at becoming the new scala command. It’s straightforward to install, has almost no dependencies, and allows users to write and run Scala code on the JVM, from javascript, and natively, with full IDE support via Metals.

Scala CLI is a great tool for experimenting with new libraries, or for scripting in Scala. Its new publishing support, and its existing cross-compilation support, make it the perfect tool to write, compile, test, and publish micro-libraries.

We’ll show that its publishing support makes it much easier than today’s Scala build tools to write cross-platform small libraries, and setup publishing to Maven Central, automating many of the steps users do manually for now.

The Scala community is not only made of frameworks and libraries, job offers and educational videos. The Scala community is made of people, even though after more than two years of remote work and virtual meetups we might have forgotten about that a bit. So here it is: a talk to remind us of that the community is a community of people. Ambitious, hard-working, hopeful, imaginative, affectionate, but also sometimes stressed out, and fearful what the future will bring. Team builders and lone wolves.

Today we want to tell you about the Scala people in Ukraine. Who and when started working with Scala. What events were the first. What companies saw its potential and started hiring Scala developers. But also where are they now and what do they dream of. We will try to answer the question how can we help the Ukrainian Scala community to survive and grow again after the war, but we also want to convince you that this is an opportunity for yourselves - to meet new people, to start new projects, to make friends.

With the recent release of Scala 3, we’ll see an increasing number of projects adding support for it alongside a couple of older versions like 2.12 and 2.13.

Apache Kafka represents an interesting use case, since it’s written in both Java and Scala, with the core module being almost completely written in Scala and currently supporting Scala 2.12 and 2.13. Adding the support for Scala 3 is a required task if we want to avoid a complete rewrite.

We took the challenge and this session explores our migration attempt, starting by stating the main problems unearthed while proofing how complicated the migration would be. The talk will then cover the missing pieces in the ecosystem, like the interoperability between Java and Scala, or differences in bytecode generation and suggest how the community can help.

Why did those problems occur and what does it need to change to have even smoother migrations in the future? Check out our experience and learn how this can be extrapolated to other mixed Java/Scala OSS projects.

The Functional Programming literature is full of words like Monad, Functor, … which can be a little bit intimidating at first. Most explanations tend to not help much with that - encoding effects, category theory… this can be properly terrifying for down-to-earth developers that just want to write some code.

The purpose of this talk is to show how these abstractions come up very naturally in very concrete projects, and how they allow you to think about the problem you’re trying to solve rather than focus on irrelevant noise.

At the end of the talk, attendants will have a solid intuition for what Functor, Apply, Applicative, FlatMap and Monad are, what problem they solve and how, and when (or when not) to use them.

In this talk, we present an automated approach for formally verifying the correctness of functional programming assignments. Our approach takes a small set of reference solutions and a set of student submissions and checks, for each submission, whether it is provably correct. We start by introducing our technique for automated equivalence checking, using the Stainless verification system. Our approach automatically matches function calls, generates proofs by induction, and checks them using SMT solvers. We then present our clustering algorithm that efficiently treats many programs at once. We conclude by demonstrating the effectiveness of our approach in practice, looking at various introductory Scala exercises.

Starting from scratch, we build a small Scala.js application with a minimal, live-editable bar chart. We show a setup for a fast save-refresh cycle. We use the following technologies:

• VS Code with Metals as IDE
• sbt, with the sbt-scalajs plugin
• Vite, a fast JavaScript packager and development server
• Laminar, a Scala.js UI library based on FRP (Functional Reactive Programming)
• Chart.js, a JavaScript library to display nice graphs
• ScalablyTyped, to get static types for Chart.js

A significant portion of the talk focuses on Laminar and its FRP model. We do not talk about the server-side aspects.

Debug Server: How we use the Java implementation of the DAP (Debug Adapter Protocol) to build a basic debugger for Scala in Metals: add breakpoints, pause the program, inspect the call stack and the local variables.

Expression Compiler: The expression compiler can compile any Scala expression into a class file, that can be loaded and executed at runtime. I will tell the story of how we built it: from the initial ideas to the current implementation. I will take some concrete examples to show how it supports the most powerful features of the language, like the contextual abstractions or the macros. This is also an opportunity to discover the internal architecture of the Scala 3 compiler.

Step filter: The step filter allows the debugger to skip the methods that are entirely generated by the Scala compiler. In this part we will see how the Scala compiler translates Scala code into Java class files and how we can decompile some information back to Scala definitions using Tasty.

Grackle is a GraphQL server based on libraries from Typelevel stack (cats, FS2, circe). It has the unique ability to configure a mapping between GraphQL queries and SQL queries. It can also use in-memory collections instead of SQL database. It is available for Scala 3 (as well as for Scala 2). We would like to present this emerging solution.

We want to cover Grackle from the user point of view and also its internals: compilation of GraphQL into a query algebra and its interpretation for in-memory mappings as well as compilation to SQL for DB-backed mappings.

Have you ever been confused by implicits in Scala? I most certainly have. I struggled to understand them at the beginning of my Scala journey, and to this day I trip over them regularly. It doesn’t help that one keyword can be used for many different things - defining Implicit parameters, implicit conversions, or type class instances. And sometimes it’s so frustrating when your code doesn’t compile because you can’t remember the magical implicit import incantation that is needed (the problem also known as “why does it work fine in that other file, but not here?!”). Scala 3 addresses a lot of the tricky bits in the language to make it clearer and easier to use, and luckily, implicits have also undergone a redesign. Well, to be precise… they’re gone. But in their place, we’re getting language constructs that do one thing and do it well. Please join me in welcoming the new keywords: “given” and “using”, as well as context functions and extension methods. They’re the new kids on the block to define our contextual abstractions, and they’re here to make our code more expressive and easier to understand. Let’s see them in action.

Micro-services are an extremely common development pattern in the industry. There are a ton of libraries and frameworks focused on making their development as easy and painless as possible. As soon as we introduce the streaming keyword however things change, this is now a much more niche problem with different characteristics. Most frameworks do not offer built-in support for them and building them using low-level libraries like Akka can be a slow and difficult process.

Spekka is a library built upon and extending Akka with the objective of making the development of streaming micro-services as productive as possible.

In this talk we will use Spekka to develop a simple but somewhat realistic stateful streaming micro-service, starting from the raw input, expanding our implementation along the way to consider aspects like fault tolerance and scalability.

Context functions made their debut in Scala 3.0, but are still alien to many Scala developers. In my talk I’d like to tame the beasts and benefit from them.

First, I will start with the basics. I am going to explain where the idea of context functions came from and what problem they intended to solve. Then I will show how to put them to work by creating simple DSL.

Subsequently, we’ll get to know the unexpected sides of the beasts: How they interact with type inference, the weirdest part of the context functions. I’ll go into more detail and explain why context functions behave differently from ordinary functions in the type system.

Lastly, I’ll tackle an important question: “Is it true that context functions don’t compose well?” I’ll show the common pitfalls and how to avoid them, and I’ll reveal some nifty hacks that I came across while experimenting.

I hope that after this talk, the listeners will be able to use and understand context functions but also understand where and how they can safely use them and where they should avoid them.

Technically, the talk will show how to achieve this by implementing a thin DSL layer on top of the Spark DataFrame API. Particularly, it will show how this DSL builds upon common functional programming patterns and concepts such as Kleislis, type classes, type-level computing, etc., taking advantage of common libraries of the Scala ecosystem such as cats, shapeless, etc.

It so happens that functional languages can be used as theorem provers, by virtue of the so-called Curry-Howard correspondence. Besides its theoretical significance, there is an appealing practical corollary: using logic exercises and recreational puzzles to improve our mastery of our language of choice, Scala. This talk has precisely the goal of explaining type-driven development and basic features of the Scala 3 type system, using Aristotle’s syllogisms, Raymond Smullyan’s Knights and knaves puzzles, and common propositional tautologies. In particular, we will see how signatures built upon algebraic data types and dependent types allow us to model these logical problems, and how type-driven development mimics the logical reasoning used to find the corresponding proofs.