0.11 scala26 2026-10-12 2026-10-13 2 00:05 https://cfp.scaladays.org https://cfp.scaladays.org/media/scala26/img/logo_SDrJdZG.webp Europe/Berlin Kesselhaus Keynote 2026-10-12T09:00:00+02:00 09:00 01:00 Coding agents are fundamentally upsetting our routines and expectations about software development. Are we witnessing the end of (human) programming, where software construction will be exclusively the domain of agents? Many claim so, but I would like to think otherwise. I believe it's essential that humans stay in the loop, even if large parts of a software system will be written and reviewed by agents. To achieve this, we will likely need fundamental changes in programming languages and programming workflows, This talk will start the discussion about what kind of possible innovations could help. scala26-106250-opening-session-keynote-the-end-of-programming Martin Odersky en false https://cfp.scaladays.org/scala26/talk/JEQ8GD/ https://cfp.scaladays.org/scala26/talk/JEQ8GD/feedback/ Kesselhaus Talk 2026-10-12T10:30:00+02:00 10:30 00:30 sbt 2.0 is a new major series of sbt that propels itself to the modern standards. In this talk, we will focus on the new features such as the native client, Bazel-compatible caching, and new test command. We will also go over the plugin migration effort, the differences between sbt 1 vs 2, and common pitfalls during migration. scala26-99382-sbt-2-0-takeoff Eugene Yokota en Building on 'sbt 2.0: go big' talk I gave, which provided visions and background around sbt 2.0 project, we can shift the focus more towards the user experience of sbt 2.0 (which would be available by Scala Days 2026). ### Summary The talk will pick up a few common tasks such as `test` and `run` that have completely changed its behavior, and explain the concrete differences between sbt 1 vs 2. We will also focus on some of the `build.sbt` example that breaks cache hermeticity to highlight caching pitfalls. ### Relevance I think this would be a relevant talk for the community given the wide usage of sbt (85.7% in 2026 survey), involvement of Scala Center + Sovereign Tech Agency, and hopefully general interest around what's new with sbt. ### Takeaway - General understanding of key features such as common settings and cached tasks - Major differences between sbt 1 vs sbt 2 - Pointers to learn about sbt or migration later false https://cfp.scaladays.org/scala26/talk/FZDGGW/ https://cfp.scaladays.org/scala26/talk/FZDGGW/feedback/ Kesselhaus Talk 2026-10-12T11:20:00+02:00 11:20 00:30 What can one tiny function teach you about twenty years of Scala? We rewrite `isPalindrome` version by version and let the code tell the story. Watch it grow from classic Scala 2 into the modern Scala 3; tail recursion, type classes, extension methods, all earning their place. A palindrome reads the same both ways, Scala's history does not. scala26-100027-a-brief-history-of-scala Odd MöllerMartin Zachrison en Scala has spent over two decades reinventing how to write code. New syntax arrives while some idioms slip into retirement, and the obvious way to express something in 2010 can look very different by 2026. Rather than march through the changelog, we tell that story with the help of a simple function: `isPalindrome`, as it evolves with Scala versions. We start with a one-liner and let the problem itself pull in new language machinery, one feature at a time, only adding things when they are needed. We will look into generalizing from `String` to `Seq[A]`, using tail recursion with `@tailrec`, and sequence extractors `+:`/`:+` that peel a palindrome from both ends in a single pattern. Asking what "equal" even means walks us through type classes as implicits and their given/using reincarnation. We close by letting the answer say something more than just `true` or `false`, contrasting sealed-trait ADTs with Scala 3 enums, and wrapping the whole thing as a fluent extension method. Each step fits on a single slide, and together they become a tour of Scala's evolving style via type abstraction, recursion, the implicits-to-givens transition, ADTs, and extension methods. Audience members leave with a timeline of Scala's syntax and idiom changes, a clearer sense of why features were added rather than merely that they were. No prior history required; just a fondness for strings that read the same both ways. false https://cfp.scaladays.org/scala26/talk/LS3ZDZ/ https://cfp.scaladays.org/scala26/talk/LS3ZDZ/feedback/ Kesselhaus Lightning Talk 2026-10-12T12:10:00+02:00 12:10 00:05 What optimizations can we find by making a simple change to a traditional data structure? In the summer of 2026 I developed a faster immutable linked list; implementing it was my first experience both writing Scala and working with an open source community. This talk explores my approach to data structure optimization and my acquisition of Scala. scala26-103107-a-maiden-voyage-into-open-source-datatypes-and-scala L Denney en What if we take a traditional data structure and make a small change to it. What kind of optimizations and use cases could we exploit by simply thinking beyond what we already use every day. This is a question I tackled with support from Google Summer of Code and the Typelevel community for 3 months through the summer of 2026. Immutable linked lists are important data structures for many functional programming applications, notably in concurrency, but what if a simple change could make them faster. Many of the most common operations we want on a list require as many pointer dereferences as elements in the list, including appending, concatenation, and methods like map and filter. Now imagine generalizing the idea of the linked list where instead of each node holding only a single element, each node holds a block of elements: each is an array of a constant size. By making this simple change, we can decrease pointer dereferences by a factor of the size of the block! Furthermore, we can use benchmarking to select an optimal block size and discover other areas where improvements can be made. I proposed the above project to Typelevel back in April of 2026. As for my background, I’ve loved functional programming since I took the introductory class in my third year of university. I went on to TA the class for three semesters, fortifying my functional programming foundations and learning how to teach a paradigm many students have never encountered before. When my project proposal was accepted and I began work on it, I had never touched a Scala program before. As of writing this description I am a mere 4 days into the project, and already I have learned so much about Scala. I expect the talk to be about the process of developing this block linked list datatype, interwoven with reflections and observations on the process of learning Scala and participating in the Typelevel community. This talk has two primary goals: - To make exploring data structures optimizations approachable, worthwhile, and fun! - To give insight into the experience of learning Scala and contributing to open source for the first time. Outline of the proposed talk - Introduction/motivation - Project Description - Personal background - Overview of the process of developing the new datatype, through the lens of navigating a new community and programming language - Final reflections on the experience false https://cfp.scaladays.org/scala26/talk/MKMNWA/ https://cfp.scaladays.org/scala26/talk/MKMNWA/feedback/ Kesselhaus Lightning Talk 2026-10-12T12:20:00+02:00 12:20 00:05 Recent work in the [scala-wasm fork](https://github.com/scala-wasm/scala-wasm) of Scala.js has made it possible for Scala apps to run directly on the WebAssembly Component Model platform. In this talk, I will share my progress of porting Cats Effect and FS2 libraries to this shiny new architecture. scala26-103150-cats-go-wasm-wasi-typelevel-on-server-side-webassembly Mariusz Jakoniuk en [The WebAssembly Component Model](https://component-model.bytecodealliance.org/introduction.html) is a new platform for building secure, composable Wasm applications with explicitly defined, type-safe interfaces. All communication between Wasm components and the outside world has to go through standardized interfaces such as [WASI](https://wasi.dev/). As a result of this design, all Scala code directly accessing platform-specific APIs has to be ported over to this new platform. This year, [my proposal](https://summerofcode.withgoogle.com/programs/2026/projects/vibpm0UF) to port core parts of the Typelevel stack onto the Wasm/WASI platform was chosen for the [Google Summer of Code program](https://summerofcode.withgoogle.com/). Even though the resulting code is still a prototype, it makes it possible for several real-world apps to "just run" as Wasm components with little to no changes. In this lightning talk, I will briefly go over the set of core I/O mechanisms used by Cats Effect and FS2 and describe their prototype implementation for the WASI 0.2 API. false https://cfp.scaladays.org/scala26/talk/GLEFDT/ https://cfp.scaladays.org/scala26/talk/GLEFDT/feedback/ Kesselhaus Lightning Talk 2026-10-12T12:30:00+02:00 12:30 00:05 Inline traits are a language feature that eliminate allocations and virtual dispatch associated with trait composition in Scala. They do so by inlining their methods into their implementing subclasses. When inline traits are combined with the Specialized type class, they enable trait-based abstractions to be zero-cost. scala26-103294-inline-traits-for-specialization James You en Specialization is a compiler transformation that optimizes generic program code such that code using primitive types can execute without significant overhead. The @specialized annotation in the Scala 2 programming language allowed programmers to direct the compiler to create optimized generic data structures for each primitive type. @specialized is used significantly in the implementation of high-performance Scala 2 libraries, allowing for performance without the productivity of generics. This optimization trades performance at the cost of extra space, as generic code must be specialized for each of the primitive types, scaling exponentially on the number of type parameters. Since the Scala 3 programming language has evolved significantly from Scala 2, the @specialized annotation is no longer available. This talk will briefly describe a new scheme of specialization for the Scala 3 compiler based on inline traits. false https://cfp.scaladays.org/scala26/talk/XZN3MU/ https://cfp.scaladays.org/scala26/talk/XZN3MU/feedback/ Kesselhaus Talk 2026-10-12T14:10:00+02:00 14:10 00:30 With Scala 3.9 LTS out, three Scala distributions will exist in parallel: Scala Next (3.10+), the current 3.9 LTS and the old 3.3 LTS. We will explain how to think about it: why you should migrate your libraries to 3.9 LTS, what cool features have we cooked up in Scala Next, and how the standard library can evolve now that it’s no longer frozen. scala26-99571-the-state-of-scala-in-2026 Piotr ChabelskiLukas Rytz en [As I write this talk description, the first release candidate of the new Scala 3.9 LTS is being prepared in the background. By Scala Days ‘26, Scala 3.9 LTS will be out in the wild, likely with Scala Next already at 3.10 series.] Scala 3.9 LTS is the second LTS series in the history of Scala, 3 years after its predecessor, 3.3 LTS. We bumped the required JDK to 17 and packed many new features, such as named tuples, better for comprehension loops, a new language runner (Scala CLI) or a bytecode optimizer. Scala 3.3 LTS still works with older JDKs and will be supported for at least another year. That should be a sufficiently long window for the community to migrate, as currently it is the most widely used distribution. Scala 2.13 will also continue receiving security and bug fixes, as well as JDK compatibility updates. We will take an early look at Scala 3.10, which will drop a number of legacy constructs to make space for new features. The standard library is getting unfrozen and open to contributions from 3.10 onwards, with a dedicated process in SLC. We will explain how (and why) it differs from SIP and what kind of changes would be accepted. In this talk we will trace where Scala is today, where we are taking it, and how you can help shape it. false https://cfp.scaladays.org/scala26/talk/EDJA7U/ https://cfp.scaladays.org/scala26/talk/EDJA7U/feedback/ Kesselhaus Talk 2026-10-12T15:00:00+02:00 15:00 00:30 We present a new Scala framework that picks ideas from Django, Spring, Rails, and a few others, and integrates them in a way only Scala can. We aim to show that building and deploying powerful applications can and should be easy in Scala, and not just for experts. scala26-99524-shopping-for-a-scala-framework Daniel CiocîrlanRiccardo Cardin en Scala deserves a great web framework. We're building it. Our framework builds around a few big ideas: 1. Your data model is the source of truth, and everything else (schemas, resources, endpoints, serialization) can be derived. 2. Capabilities are visible in all critical signatures, so the compiler stops you if you're trying something without the necessary resources. 3. Server-rendered, server-stateful UI with real-time updates over a tiny WebSocket runtime (a few KB). 4. Boring infrastructure and simple commands. The framework comes with its own CLI to deploy applications in seconds. The result combines (what we think are) the best parts of existing frameworks, like Rails, Spring, and Phoenix, with the power of Scala to produce an exceptionally high productivity framework. In our talk we will create a non-trivial application in only thirty minutes, which will demonstrate the features we described above and prove our claim about productivity. By the end of the talk, we hope that you'll get curious and excited enough to try this framework on a new project. This framework, if successful, has the potential to - put Scala back on the map for application development, 10 years after Play’s peak relevance; - attract newcomers to Scala; and - create new startups which are the beginning stage of the adoption cycle (in terms of both people and companies) and you are the first audience to see it live. false https://cfp.scaladays.org/scala26/talk/7KYEXS/ https://cfp.scaladays.org/scala26/talk/7KYEXS/feedback/ Kesselhaus Talk 2026-10-12T15:50:00+02:00 15:50 00:30 WebAssembly is increasingly used beyond browsers for serverless, sandboxing, AI workloads, and more. This talk explores the current state of Scala on Wasm with Scala.js and scala-wasm, an experimental project targeting standalone runtimes, WASI, and the Component Model. This session covers current capabilities, limitations, and future directions. scala26-98544-the-state-of-scala-on-webassembly Rikito Taniguchi en WebAssembly is increasingly used beyond the browser for [serverless](https://www.akamai.com/blog/developers/build-serverless-functions-zero-cold-starts-webassembly-spin) platforms, [sandboxed execution, AI workloads](https://thenewstack.io/webassembly-sandboxing-ai-agents), and more. As the Wasm ecosystem grows, it is no longer limited to systems languages such as Rust and C++ [Scala.js now supports a Wasm](https://www.scala-js.org/doc/project/webassembly.html) alongside JavaScript, and the [scala-wasm](https://github.com/scala-wasm/scala-wasm) project explores [Wasm/WASI](https://wasi.dev/), and the [Component Model](https://component-model.bytecodealliance.org/). **This talk covers what currently works and what remains experimental, what WASI and the Component Model are, how they can be used from Scala, and the practical benefits of compiling Scala to Wasm.** Topics include: - How to compile and run Scala applications on Wasm - The current state of the Scala Wasm backend - The basics of WASI and the Wasm Component Model - How Wasm sandboxing protects you from AI - How to build serverless Wasm applications in Scala false https://cfp.scaladays.org/scala26/talk/XSQMQV/ https://cfp.scaladays.org/scala26/talk/XSQMQV/feedback/ Kesselhaus Talk 2026-10-12T16:40:00+02:00 16:40 00:30 Modern distributed systems depend on caching for performance, yet implementing caching correctly and safely remains a persistent challenge. This talk explores how Cats Ref from the Typelevel ecosystem enables developers to build thread-safe, testable cache while maintaining functional purity. scala26-98744-caching-in-scala-using-cats-ref Katrina Petrevice en Through hands-on exploration of Cats `Ref` and a realistic API caching scenario, this talk exposes the subtle pitfalls that commonly catch developers off guard when implementing `Ref`. Rather than learning these lessons painfully through production incidents, the talk provides practical strategies to recognise, prevent, and test them from the start. The talk will aim to establish foundational knowledge; what `Ref` is, why it represents the ideal abstraction for concurrent cache implementations, and how it maintains both safety and purity in the presence of mutability. Building on this foundation, the talk examines core caching principles, exploring when caching is appropriate and how to choose strategically between in-memory and cloud-based solutions. By the end attendees should gain confidence implementing `Ref` with a clear understanding of its behaviour and implications beyond that of caching. The talk has been previously presented at London Scala User Group (LSUG) to a diverse audience, including those unfamiliar with the Typelevel stack. As the speaker I bring three years of production Scala experience, whereby I have used `Ref` for caching large scale business data models for quick retrievals and dynamic configuration updates without server restarts. I aim to bring fresh perspectives on `Ref` with direct takeaways from my experiences with Typelevel stack. false https://cfp.scaladays.org/scala26/talk/8PAEJW/ https://cfp.scaladays.org/scala26/talk/8PAEJW/feedback/ Kesselhaus #ScalaDays 2026-10-12T18:00:00+02:00 18:00 04:00 ScalaDays is a good place to meet great people, and while there is ample time to chat and discuss during the conference, we also want to provide an opportunity for everyone to meet up outside of the regular conference program with our Community Party on Monday! Our Community Party will take place at Frannz Salon. It is a casual meet-up in a relaxed atmosphere and provides a perfect opportunity to meet old and new friends, business contacts or get to know other participants of ScalaDays. We will offer food as well as alcoholic and non-alcoholic drinks. scala26-106270-community-party en false https://cfp.scaladays.org/scala26/talk/PCDP8E/ https://cfp.scaladays.org/scala26/talk/PCDP8E/feedback/ Maschinenhaus Talk 2026-10-12T10:30:00+02:00 10:30 00:30 Representing user interfaces as effects in the capability-passing style gives a simple framework for creating UIs. In this talk I'll explain how capability-passing works and use it to implement a simple terminal user interface library. We'll then discuss what general principles we can take from this, that can apply to any problem. scala26-98940-simpler-user-interfaces-with-capability-passing Noel Welsh en **Description** Modern user interface libraries represent interfaces as effects in the capability-passing style. Scala 3 has excellent support for this style of programming. I'll demonstrate this by implementing a simple terminal user interface framework in the capability-passing style. The resulting framework is straightforward to use, and catches certain classes of errors at compile-time. I'll then describe the general principles we can take from this exercise, giving you the mental models to use capability-passing in your own projects. **Goals** The main goals of this talk are: 1. To show that capability-passing is a useful tool, by building a simple terminal user interface framework with it. 2. To abstract the design into general principles for creating frameworks using capability-passing. **Outline** - Effects, context, and capabilities. Explain three core ideas of effects, context, and capabilities. Describe the goals of an effect system: tracking effect usage and preventing effects when it is not safe to use them. - Interfaces are hard. From a simple UI example, examine the underlying issues and see why they are difficult to implement. We'll see we need to create two structures, the layout tree and the event graph, and these structures have mutual dependencies. - Modern frameworks. Look at an example modern user interface framework (probably Jetpack Compose, as it has all the features I want to show) and see how it solves the problems. Show that this is capability-passing, but not made explicit. - User Interfaces in Scala. Can we do better in Scala? Of course we can. Implement a basic terminal user interface framework in Scala. Show we can represent both the layout tree and event graph as capabilities, using just language features in Scala. - Type systems squash bugs. Show how we can use the type system to prevent simple but annoying bugs, such as using an event source outside a reactive scope. Talk about how capture-checking can prevent more bugs (but I probably won't have time to go into details.) - Capability-passing as a design strategy. Abstract what we've learned. We can build tree structures, more flexibly than with algebraic data types, using capability-passing. We can also build graph structures if we reify graph vertices. Finally, we can do away with sequencing combinators such as `map` and `flatMap` and just run in "direct-style". Show how this still retains desirable properties of reasoning and composition. false https://cfp.scaladays.org/scala26/talk/SLQC7Y/ https://cfp.scaladays.org/scala26/talk/SLQC7Y/feedback/ Maschinenhaus Talk 2026-10-12T11:20:00+02:00 11:20 00:30 AI is a multiplier, not a fixer — point it at a mess, and it scales the mess up: defects climb, reviews balloon, tests become a farce. Scala's honest compiler and typed libraries are a base that holds as you push harder. We'll assemble the workflow around them with agents, context, deterministic refactors, hermetic builds and more. scala26-100040-ai-multiplies-let-scala-hold-the-line Krzysztof Romanowski en A year ago, my argument was that productivity lives in the whole development lifecycle, not in how fast anyone types. AI hasn't changed that — it made it unforgiving. The instinct is to treat an agent as a fixer, something you point at a problem to make it go away. It isn't. It's a multiplier, and a multiplier obeys whatever it's standing on. Direct it at a shaky team process, and nothing gets repaired; the shakiness simply scales. More defects, longer review queues, green test suites that are quietly wrong — and reworks that grow faster than anyone wants to admit. Which reframes the whole question. It’s not "how do we add AI?", it’s "what is it multiplying?" For Scala teams, the honest answer is the language itself. Strongly typed libraries and a compiler that refuses to lie give you a foundation that gets firmer under pressure. This allows to discover failures at runtime - the kind of failures that only surface at runtime on production with other stacks.. The types you already have are complex enough. What's usually missing is a process built to lean on them. So that's what we'll assemble, one component at a time, like building together a kit. Context Fabric, CI build for Machine Speeds, Tiered Review and testing strategies for the AI era. We will apply the same discipline we've been using in large monorepo teams — the Airbnb and Databricks tier — where we're seeing output climb by roughly half in a matter of months, but in a way that can be split and rearranged to match your context. You won't leave with a mandate to adopt all of it. You'll leave with the kit, the cost of each piece, and a clear sense of what to reach for next on your own Scala projects — a way to raise productivity and quality at the same time, instead of trading one for the other. false https://cfp.scaladays.org/scala26/talk/EYKYAL/ https://cfp.scaladays.org/scala26/talk/EYKYAL/feedback/ Maschinenhaus Talk 2026-10-12T14:10:00+02:00 14:10 00:30 Java has LibGDX. Scala has powerful platforms, but not the same game-development story. SGE is my attempt to close that gap. This talk is about the engineering needed to make one Scala codebase run across desktop, browser, native and Android targets. scala26-99964-scala-s-libgdx-a-report-from-the-trenches Mateusz Kubuszok en In this talk I will describe how the initial goal of building a Scala game engine with LibGDX-like reach led to a series of deeper platform-engineering problems: how to port a large Java ecosystem with LLMs without trusting them blindly, how to track source parity, tests and coverage, how to build sbt tooling for multi-architecture JVM packaging and Scala Native cross-compilation, and how to ship native dependencies with the right linker flags for each platform. The audience will see SGE as a case study in ambitious multi-platform Scala: what works today, what fights back, and what still needs to improve. The talk is not mainly about game design. It is about the infrastructure required to make Scala usable for desktop, browser, native and Android applications from one codebase. false https://cfp.scaladays.org/scala26/talk/MM3RRZ/ https://cfp.scaladays.org/scala26/talk/MM3RRZ/feedback/ Maschinenhaus Talk 2026-10-12T15:00:00+02:00 15:00 00:30 To business leadership, Scala looks like a high-risk bet: the talent is expensive and the learning curve is a wall. So why willingly sign off on a technology that makes recruiting harder? Because optimizing for cheap headcount is a false economy. This fast-paced session bridges the gap between engineering elegance and CFO mathematics. You will learn how to expose the "shadow payroll" of bloated polyglot teams, and leave armed with the exact financial vocabulary needed to prove that a lean, elite Scala team is the most aggressive risk-mitigation strategy a CTO can deploy. scala26-106178-hard-to-hire-hard-to-learn-hard-to-break-a-cto-s-scala-case Gordon Cooke en Scala Days is packed with brilliant deep dives into the "how" of the language, but this session zooms out to ask the fundamental "why." When engineers pitch Scala to business leadership, the conversation usually hits a wall. To a CTO or CFO, Scala looks like a high-risk bet: the talent is expensive, and the hiring pipeline is slow. The default corporate instinct is to mitigate this by optimizing for "cheap headcount"—often resulting in massive teams writing in verbose, weakly-typed languages. But that optimization is a false economy. In this fast-paced session, we will bridge the gap between engineering elegance and business reality by examining the true Total Cost of Ownership (TCO) in complex domains. We will expose the "shadow payroll"—the hidden layers of engineering managers, manual QA testers, and incident responders required to babysit bloated polyglot architectures. By framing Scala’s compiler as an automated compliance officer and its concise syntax as a tool for architectural leverage, attendees will learn how to identify the exact workloads where Scala wins. You will walk away with the financial vocabulary and organizational math required to prove to your stakeholders that a lean, elite Scala team is ultimately far more cost-effective than a sprawling alternative. false https://cfp.scaladays.org/scala26/talk/G79UPY/ https://cfp.scaladays.org/scala26/talk/G79UPY/feedback/ Maschinenhaus Talk 2026-10-12T15:50:00+02:00 15:50 00:30 Metaprogramming is the act of treating code as data, to transform it, yielding new programs. Is that not also what functional programming is all about? Similarly, what does compile time mean, when mixed with IO, where programs are constructed and run in separate phases? Let's talk about it together. scala26-97351-is-metaprogramming-just-functional-programming Kathryn Frid en What is metaprogramming? Definitionally it is just manipulating code as data, to produce new programs. By that logic, is `map` and `flatMap` not metaprogramming? Is is metaprogramming if you use `inline`? What about if you use quotes and splices? How does compiletime vs runtime factor into this? How about with something like `IO`, where all you are really doing is putting together a program from smaller pieces? What does compiletime vs runtime mean there? How about program analysis? That is metaprogramming, and not something functional programming can do as easily, right? I do not have the definitive answer to any of these questions, but I hope we can discuss them together, and maybe come closer to some idea about how metaprogramming and functional programming are similar, but possibly still different. If you've never interacted much with metaprogramming before, I hope I can give you an introduction of sort, not on how to do it, but why. false https://cfp.scaladays.org/scala26/talk/LXXBWY/ https://cfp.scaladays.org/scala26/talk/LXXBWY/feedback/ Maschinenhaus Talk 2026-10-12T16:40:00+02:00 16:40 00:30 Can high-level code have the same perf as low-level hand-tuned code? That’s what Scala’s optimizer is for! Your call to map on a list turns into the same bytecode as if you had written a while loop. In this talk, I’ll introduce bytecode and optimization basics, present the Scala optimizer, and discuss fundamental and temporary limitations. scala26-98925-optimizing-scala-bytecode-for-fun-and-profit Solal Pirelli en Every developer wants to write high-level declarative code that’s easier to maintain while also getting the performance benefits of low-level imperative code that doesn’t pay the costs of abstraction. The Scala compiler has a bytecode optimizer to help reach that goal, and the JVM also performs its own optimizations. However, there are plenty of interesting problems and tradeoffs along the way. For instance, while inlining code can help avoid virtual calls and allocations, it can also cause slowdowns from having too much code to load and keep in the instruction cache. Even if a specific optimization is profitable, it may rely on such a specific code shape that it is too brittle to be depended upon. Optimization has its limits, and the JVM adds its own limitations on top of those, which aren’t the same as in other targets such as Scala.js. In this talk, I'll discuss: - what bytecode is, and how the JVM interprets and compiles it; - a high-level view of optimizations, including inlining, store-load elimination, and so on; - how the optimizer is implemented, and what consequences this has on the optimizations it performs; - what developers can and cannot expect from the Scala compiler and the JVM; and - how the Scala optimizer could improve in the future. false https://cfp.scaladays.org/scala26/talk/8RMYG9/ https://cfp.scaladays.org/scala26/talk/8RMYG9/feedback/ Palais Atelier Talk 2026-10-12T10:30:00+02:00 10:30 00:30 Typelevel participated in the **GitHub Secure Open Source Fund** this year. This talk shares what we learned, what we are now doing to secure the Typelevel ecosystem, and **how you can improve security in your own projects**. We will also briefly discuss the requirements of the new EU Cyber Resilience Act. scala26-99869-securing-typelevel-lessons-from-the-github-sos-fund Antonio Jimenez en **Open source security has never mattered more.** In the last few years we have lived through Log4Shell, the xz backdoor, and a steady stream of npm and PyPI supply-chain attacks. AI is now being pointed at codebases to discover exploits at machine speed, and regulators have noticed: The EU's **Cyber Resilience Act** took its first effect in September 2026. Earlier this year, Typelevel was selected for the **GitHub Secure Open Source Fund**, a three-week intensive run by the GitHub Security Lab to help critical open source projects improve their security posture. We covered security advisories and incident response, threat modeling, hardening GitHub Actions, CodeQL, fuzzing and the security implications of AI and LLM tooling. This talk shares that work in three layers. **First, what we learned in the program:** the practices, the tooling, the homework and how any project, open source or internal, can apply them. **Second, what Typelevel is now doing across its ecosystem.** Some of these practices pre-dated the program, but the fund gave us the structure to review, formalise, and apply them consistently. We are now rolling out a shared baseline of repository settings across all Typelevel projects: private vulnerability reporting enabled, code scanning, secret scanning, MFA enforced for maintainers. We have also reviewed and updated the security documentation: an incident response plan, a threat model outline, and a fresh look at project licenses. We will also walk through how Typelevel handles a CVE end-to-end — from a private vulnerability report landing in our inbox, through coordinated disclosure, to the published advisory and patched release. **Third, the EU Cyber Resilience Act,** which was adopted in late 2024 and entered into force on 10 December 2024. Its first wave of obligations — mandatory reporting of actively exploited vulnerabilities and severe incidents to ENISA and national authorities — has applied since **11 September 2026**. Any company placing a Scala-based product on the EU market now falls under the regulation, and their compliance story has to account for every dependency they ship. We will share what Typelevel is working through as a foundation that sustains critical open source, and what that means for downstream users. If you maintain an open source Scala library, ship a Scala service into production, or depend on the Typelevel stack, you will leave with **a checklist, a clearer view of what's coming and a working model for handling vulnerabilities** when they show up. false https://cfp.scaladays.org/scala26/talk/R87B7Z/ https://cfp.scaladays.org/scala26/talk/R87B7Z/feedback/ Palais Atelier Talk 2026-10-12T11:20:00+02:00 11:20 00:30 Object-oriented programming helped shape modern software engineering — but also gave us shared mutable state, fragile hierarchies, and accidental complexity. Using real Scala adoption stories, this talk explores why legacy OOP thinking fails and how functional principles help teams build simpler systems. scala26-99249-how-oop-earned-our-trust-and-let-us-down Pavel Kozlov en Object-oriented programming dominated software development for decades. It improved code reuse, abstraction, and modelling, and many developers — myself included — started their careers with it. But over time, the same ideas often produced systems that became difficult to reason about: shared mutable state, deep inheritance trees, overengineered patterns, and growing technical debt. In this talk, I’ll share lessons from real-world Scala adoption projects where the biggest challenge was not learning a new language, but bringing existing habits into a different paradigm. Instead of embracing immutability, pure functions, and explicit effects, teams often recreated familiar OOP architectures with shinier syntax — and repeated the same mistakes. Through practical examples we’ll examine how good engineering intentions can still lead to systems that are harder to maintain and evolve. Finally, I’ll show how functional programming principles can help teams write simpler and more sustainable software — not only in Scala, but across modern language ecosystems. Attendees will leave with practical ideas for reducing accidental complexity and avoiding common overengineering traps. false https://cfp.scaladays.org/scala26/talk/SEEJRS/ https://cfp.scaladays.org/scala26/talk/SEEJRS/feedback/ Palais Atelier Talk 2026-10-12T14:10:00+02:00 14:10 00:30 How do you achieve reliable results from stochastic AI models? This talk presents practical techniques for building quality pipelines around generative AI that improve output quality before human review begins, making more effective use of limited human time and attention. scala26-99800-quality-pipelines-for-generative-ai Bill Venners en Generative AI can generate useful content at extraordinary speed, but the quality and reliability of that output remain uneven. Raw AI output can contain subtle errors, inconsistencies, weak explanations, or questionable engineering choices. Human review remains essential, but once AI can generate content at scale, human attention itself becomes the bottleneck. This talk presents an engineering approach to improving the quality of generative AI output before humans enter the loop. Rather than treating AI as a standalone assistant, we can build “quality pipelines” around it using deterministic programs, repeatable workflows, structured review loops, iterative refinement, and layered human vetting. As a case study, I’ll describe work done for an STA (Sovereign Tech Fund) Scala Center project that focused on improving the documentation of the Scala standard library. We wrote Scala programs that inserted TODO markers into `.scala` source files where Scaladoc was missing. We then used long-running Scala scripts to orchestrate an AI-driven workflow that generated documentation, reviewed generated text, produced structured feedback, and iteratively refined the results one file at a time before multiple stages of human review. In this talk, you will learn practical approaches to building quality pipelines around generative AI, including deterministic orchestration, structured review loops, iterative refinement, and layered human vetting. The session will focus on applying traditional software-engineering ideas to AI systems to achieve the quality you want while making the most effective use of the precious resource of human attention. false https://cfp.scaladays.org/scala26/talk/WQVZSC/ https://cfp.scaladays.org/scala26/talk/WQVZSC/feedback/ Palais Atelier Talk 2026-10-12T15:00:00+02:00 15:00 00:30 Where does computation live? In origami, it lives in a paper crease. We build a functional crease pattern generator in Scala to explore what origami teaches us about programs. The insight is material before it is mathematical: pure functional programming emerges naturally from the physics of folding. scala26-99899-on-folding Johanna Odersky en This talk uses origami as a concrete, geometric setting for ideas that often stay abstract. We walk through the implementation of a crease pattern generator in Scala: a program that takes a set of folding rules and produces the geometric blueprint for an origami model. The patterns we generate, we fold into physical objects. Along the way, the talk covers how to model a physical system as immutable data and how to encode mathematical laws as type constraints, so the compiler rejects invalid states. We are not using functional programming as a convenient tool. Instead, we are making the argument that origami is a form of computation, and that the math enforcing which folds are physically valid is a type system. The audience will leave with a concrete example of type-driven design applied to a real domain, an intuition for why immutability and pure functions are not just good practice but sometimes the only model that fits, and (in the best case) the realisation that computation can live anywhere. Even in a sheet of paper. This talk is aimed at beginners and experienced Scala developers alike. Its goal is less to close things down than to open them up. false https://cfp.scaladays.org/scala26/talk/9UMGZA/ https://cfp.scaladays.org/scala26/talk/9UMGZA/feedback/ Palais Atelier Talk 2026-10-12T15:50:00+02:00 15:50 00:30 Scala is evolving to be more welcoming than ever. Explore the VirtusLab Scala Stack, an innovative toolkit that combines Scala 3 and Project Loom to champion direct-style programming by making concurrency more intuitive. With libraries like Ox and Tapir, the entry barrier is lowered, inviting new developers to build robust, scalable apps.​ scala26-99789-back-to-the-roots-virtuslab-scala-stack Jacek Kunicki en Scala was always meant to be simple, safe, and robust. It was designed to "scale" from short programs to big, efficient solutions. Features like higher-kinded types, the for-comprehension syntactic sugar, and Futures enabled efficient concurrency. Along the way, Scala’s sophisticated type system enabled the development of functional programming ecosystems around IO monads. This introduced principles such as referential transparency for scalability and fearless refactoring. But there was a price to pay: a steep learning curve and a reputation for complexity. These factors discourage new developers. Today, we have a solution and a way to attract new developers to Scala. The VirtusLab Scala Stack is a complete stack that combines established Scala libraries with some innovation from new ones, focusing on simple Scala through direct style. VirtusLab provides enterprise-grade support for libraries, tools, and the language itself.​ Thanks to VirtusLab Scala Stack, programmers can forget about abusing for-comprehension. Eager Futures and lazy IO monads no longer creep throughout the codebase. Developers can use the style familiar from other languages and ecosystems. This approach is supported by a strong type system together with resource safety. Could this be a new opening for Scala application development?​ During the talk, I will walk you through examples of using different libraries from the VirtusLab Scala Stack family, showcasing what they look like in direct style and how they combine, resulting in simple-to-write and read yet robust and powerful code. false https://cfp.scaladays.org/scala26/talk/JQPA8G/ https://cfp.scaladays.org/scala26/talk/JQPA8G/feedback/ Palais Atelier Talk 2026-10-12T16:40:00+02:00 16:40 00:30 At Active Group, we have taught more than 30 three-day trainings on Functional Software Architecture since 2019, mostly to audiences with little or no prior exposure to functional programming. For the examples, we use Scala or Haskell. I report on the constraints, successes, and learnings of this course. scala26-99831-teaching-software-architecture-using-scala Michael Sperber en Since 2019, the International Software Architecture Qualification board has featured a three-day curriculum for Functional Software Architecture ("FUNAR") as part of its Advanced Level certification. In our training implementing the curriculum, we work through exercises examples written in Scala (alternatively Haskell), among them a complete web application. The short duration of the course (which is usually preceded by a one-day introduction to functional programming) puts significant constraints on how much and what it can cover, but also poses didactic challenges as all material must be explainable and carry over to other functional languages. Over the past six years, we have continually assessed the effectiveness of the course and made many iterative improvements. I'll report on our experience and draw some inferences not just about teaching but also about viable software architecture in Scala and what its advantages and differences are with traditional software architecture. false https://cfp.scaladays.org/scala26/talk/VJWHRZ/ https://cfp.scaladays.org/scala26/talk/VJWHRZ/feedback/ Frannz Salon: Lab 1 Interactive labs 2026-10-12T11:00:00+02:00 11:00 02:00 Learn to **diagnose realistic production failures** in a distributed Typelevel streaming platform. Through a curated set of incidents, you will debug failures using telemetry and iteratively improve observability through manual instrumentation with `otel4s`, leaving with a practical mental model for **telemetry-driven debugging in Scala**. scala26-99860-a-distributed-system-on-fire-diagnosing-failures-with-otel4s Antonio JimenezMaksym Ochenashko en This interactive lab puts you in front of a running distributed streaming platform built on the Typelevel stack (`cats-effect`, `fs2`, `http4s`, `smithy4s`, `skunk`, `otel4s`) and asks you to **diagnose what just broke**. The system is realistic: several microservices communicating over HTTP, an `fs2` traffic generator, Postgres, and a full observability stack (metrics, traces and logs) already wired up with `otel4s` and visualized with Grafana dashboards. Everything is pre-built, pre-deployed, and runs locally with a single command. If you would rather not run anything locally, the lab will be fully available as a GitHub Codespace. We will work through a curated series of incidents covering two flavours of production pain: - **System-wide degradation:** A big chunk of the platform slows down or stops working for everyone. - **Tail-latency mysteries:** most users are fine, but a small fraction see slow or failing requests. For each incident, you will get the symptoms, access to the running system and its observability backend, and time to investigate. We will guide you through a repeatable diagnosis pipeline — **metrics → traces → logs** — that scales from trivial bugs to genuinely tricky ones. At least one scenario is designed so that default instrumentation is not enough: you will add your own spans and attributes with `otel4s` to narrow down the problem. After each round we will walk through the diagnosis together and discuss what telemetry made visible that logs alone would not have. By the end you will have a practical mental model for **telemetry-driven debugging in Scala**, hands-on familiarity with `otel4s` in a realistic distributed stack, and a take-home repository you can run locally to keep practising. **Setup requirements:** Docker, sbt, java 17+ or use github codespace. **Nice to have (but not required):** - Comfortable working with Scala and Cats Effect. - Familiarity with the basic ideas of distributed systems. --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/QXAPMM/ https://cfp.scaladays.org/scala26/talk/QXAPMM/feedback/ Frannz Salon: Lab 2 Interactive labs 2026-10-12T11:00:00+02:00 11:00 02:00 Scala Native is great! It creates small and fast binaries, and can access all operating systems features. This workshop will introduce working with Scala Native by building a terminal based application. We'll learn how to setup and build Native code, call into with system libraries, and use the archaic but powerful features of the terminal. scala26-99634-building-real-applications-in-scala-native Noel Welsh en **Overview** Scala Native is a powerful tool, but underappreciated. The goal of this workshop is to show you how to work with Scala Native, and some of the unique features it unlocks. In particular the workshop will cover: 1. Building tools with Scala Native, including project setup, building executables, and using the FFI. 2. Knowledge of working with the terminal, at both a low-level (ANSI escape codes and C APIs), and a high-level (creating terminal user interfaces using a framework) 3. An appreciation of the ecosystem that is available in Scala Native. The core of this workshop will be building an application with a terminal user interface. The exact kind of application is to be determined; current ideas are: - an HTTP client like [Slumber](https://slumber.lucaspickering.me/); - a Bluesky client; or - a todo list. You must have Scala Native installed before the workshop. Scala Native requires [some additional installation steps](https://scala-native.org/en/latest/user/setup.html) beyond installing just Scala. Furthermore, the operating system specific features we will use are only available in Unix-like systems (Linux or MacOS). If you are using Windows then you must be able to use [WSL](https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux). **Details** 1. Creating a sbt project that uses Scala Native. The Scala Native plugin, cross-project setup and its advantages. Building and linking. Finding the executable. 2. Interacting with the terminal. Basic ANSI escape codes. Features only available via operating system calls (tcgetattr, tcsetattr, ioctl). Using Scala Native's existing OS bindings. 3. Using the FFI. Binding a C function in Scala Native. C types, memory allocation. Writing C stub code to produce the value of constants. 4. Building the application. We'll switch to using [Terminus](https://www.creativescala.org/terminus/) so we don't have to build everything from scratch. This will allow us to explore the Scala Native ecosystem (e.g. Cats Effect.) --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/RC939C/ https://cfp.scaladays.org/scala26/talk/RC939C/feedback/ Frannz Salon: Lab 3 Interactive labs 2026-10-12T11:00:00+02:00 11:00 02:00 Come talk to the sbt maintainers at sbt 2.0 lab. The lab session will be a mix of prepared problems and build clinic to discuss porting your build to sbt 2. scala26-99385-sbt-2-0-lab Eugene YokotaAnatolii Kmetiuk en This lab session will be conducted by current sbt maintainers Eugene and Anatolii. ### Summary We'll prepare some example problems people can go through to experience the caching issues etc that we can finish in an hour. The next hour would be more open-ended discussion or Q&A about porting existing build to sbt 2. ### Relevance Having an in-person clinic time with the project maintainers makes conference a fruitful experience. This might also be an opportunity where people can discuss closed-sourced repo. --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/DYQWSL/ https://cfp.scaladays.org/scala26/talk/DYQWSL/feedback/ Kesselhaus #ScalaDays 2026-10-13T09:00:00+02:00 09:00 00:15 Join us as we kick off Day 2 of ScalaDays 2026! scala26-106254-welcome-back en false https://cfp.scaladays.org/scala26/talk/CCL7JZ/ https://cfp.scaladays.org/scala26/talk/CCL7JZ/feedback/ Kesselhaus Keynote 2026-10-13T09:15:00+02:00 09:15 00:45 What future of programming to do we want? How do we build it? scala26-105049-future-of-programming Nada Amin en false https://cfp.scaladays.org/scala26/talk/J7ABJP/ https://cfp.scaladays.org/scala26/talk/J7ABJP/feedback/ Kesselhaus Talk 2026-10-13T10:30:00+02:00 10:30 00:30 Learn more about Typelevel, the open source organization that stewards development of projects such as Cats Effect, http4s, and Circe, and offers one of the most comprehensive cross-platform stacks for the Scala ecosystem. In this talk, you will discover the people and processes driving this work and how you can participate. scala26-99732-a-typelevel-prospectus Arman Bilge en Typelevel as an organization has grown a lot in the last year, since we became a nonprofit Foundation. I am excited to share with the broader Scala community about everything we've accomplished, where we are going, and how they can become involved. Three goals for this talk are to: 1. Give an overview of who Typelevel is and what we do. 2. Provide transparency into our governance, community, and technical operations. 3. Share opportunities and invite the community to become involved. Along the way, I will briefly cover specific projects and initiatives in more detail, to highlight examples and success stories. More broadly, perhaps this talk will also offer insights about how to foster community and sustainable growth in open source. false https://cfp.scaladays.org/scala26/talk/ACGLZW/ https://cfp.scaladays.org/scala26/talk/ACGLZW/feedback/ Kesselhaus Talk 2026-10-13T11:20:00+02:00 11:20 00:30 The AI revolution raises questions about the utility of various technologies, especially programming languages. And when it comes to developer experience, Scala might have just the right answers. We'll take a tour of how to use Scala efficiently for and with AI. scala26-98645-where-scala-meets-ai Adam Warski en The AI revolution raises questions about the utility of various technologies, especially programming languages. And when it comes to developer experience, Scala might have just the right answers. We'll take a tour of how to use Scala efficiently for and with AI. We'll start by augmenting existing Scala development workflows with AI, leveraging Metals MCP and Cellar. Next, we'll teach AIs to write better Scala and more functional code. A short Scala skill makes a whole lot of difference in the quality of the generated code. Here we'll focus on the direct-style-Scala skill we've been developing, highlighting the main challenges that AI faced in our experiments. We'll finish by looking at applications: using Scala to orchestrate coding agents and to orchestrate arbitrary business workflows. These are two broad categories. First, we'll take a hands-on look at Orca, which offers an API for setting up deterministic, AI-driven development flows. For the second, we'll see how sttp-ai and chimp work together to provide the necessary Scala tooling to use AI models in your applications: talking to OpenAI/Claude APIs, running an agentic loop, using structured inputs & outputs. One theme will be constant: leaning on type safety and Scala's toolchain to deliver business value not only faster, but also with more reliability. In each case, we'll show where Scala is better suited than alternatives for the problem at hand - and where it loses to the competition. Our goal will be to answer the question: in the age of AI, where does Scala have the upper hand false https://cfp.scaladays.org/scala26/talk/RSEGGV/ https://cfp.scaladays.org/scala26/talk/RSEGGV/feedback/ Kesselhaus Lightning Talk 2026-10-13T12:10:00+02:00 12:10 00:05 Tests and types are our correctness gates. But who verifies the gates themselves? With agentic codegen flooding our pipelines with code we didn't write, that question has never been more dangerous to ignore. In this talk, we explore how theorem provers complement existing practices, adding mathematical certainty where it matters most. scala26-97324-stop-testing-start-proving Valentin Bergeron en Tests and types are our correctness gates. Yet nobody verifies the gates themselves. With agentic codegen flooding our pipelines at a scale we can't keep up with, that gap has never been more dangerous to ignore. This talk is about industrializing formal verification: taking theorem provers from an academical tool to a practical, deployable tool for production engineering teams. We'll look at how to identify the business logic that does: the invariants, state machines, and domain rules where a bug is not just an incident but a liability, how to scope verification to where it pays off and what are its limits. Then we will see how to ship proven code. We will present ways to deploy verified code across backends, frontends, event-driven systems, and even embedded firmware, and what changes in your architecture and codebase when correctness is a certitude. While writing proofs has been hard, writing a theorem statement is not. We'll see how AI-augmented workflows let you specify what must be true, and let the machine figure out why it is. The result is a new kind of correctness gate: interfaces, in both the type-theory and software sense, that are proven contracts, not assumptions. We started by questioning our gates. We'll end with better ones. false https://cfp.scaladays.org/scala26/talk/H9VZ79/ https://cfp.scaladays.org/scala26/talk/H9VZ79/feedback/ Kesselhaus Lightning Talk 2026-10-13T12:15:00+02:00 12:15 00:05 LLMs are changing how people contribute to open source - but are they really helping? In this talk, we’ll look at compiler maintenance in the age of AI-generated PRs, issues and comments, and ask what maintainers gain, lose, and how the rules of contribution are changing. scala26-100007-scala-oss-vs-the-llm-era Patryk Zieliński en LLMs have lowered the barrier to contributing to open source, but for maintainers the picture is more complicated than “more contributions = better”. This talk looks at how the maintenance of open source projects, including the Scala 3 compiler, changes when AI-generated issues, comments, PRs and even design proposals start showing up. We will walk through a real-looking low-effort LLM contribution and compare it with an actual fix. The interesting part is not whether the code compiles, but whether it solves the real compiler bug - or merely patches the single reproduction case that was given to the model. From there, we will zoom out to the broader stream of AI-generated open source activity: confident but wrong explanations, noisy GitHub comments, suspicious proposals, bot-authored pull requests. These examples show how much of maintainer work is not just writing code, but understanding intent, verifying claims, and deciding what is worth trusting. This is not a talk about mocking AI users. Many of us use LLMs every day, sometimes very effectively. The goal is to show what maintainers now have to review, verify, and make sense of - and why it is surprisingly hard to tell whether the LLM era is making open source maintenance easier, harder, or simply different. false https://cfp.scaladays.org/scala26/talk/T3HHRC/ https://cfp.scaladays.org/scala26/talk/T3HHRC/feedback/ Kesselhaus Lightning Talk 2026-10-13T12:20:00+02:00 12:20 00:05 Local AI assistants like OpenClaw run with shell, browser, and credentials. Open chats make prompt injection a massive leak risk. Docker fails; approvals kill UX. TACIT opened the way: capture checking makes leaking information flows uncompilable. In this talk, we will demo assistant security on browser automations against exploits. scala26-100022-ai-on-your-desktop-secure-automation-using-capture-checking Salim Belkhir en In this highly practical, demo-driven session, we will move from an exploit to a complete type-safe wrap: ## 1. The Live Exploit We will reproduce a live prompt-injection attack against an unsandboxed OpenClaw instance. We’ll show how a benign-looking incoming chat message tricks the agent into harvesting host tokens and broadcasting them to an external endpoint. ## 2. The Zero-Rewrite MCP Wrap We will walk through a 5-step architectural setup that intercepts agent actions over local MCP, disables built-in shell/file/network access, and routes all operations through TACIT's capability-typed REPL. ## 3. Under the Hood: Scala 3 Capture Checking We’ll tour the bleeding-edge static analysis machinery making this possible. Files under classified paths are automatically wrapped in a `Classified[String]` container. We will look at how the trait API leverages Scala 3 capture checking: ```scala trait Classified[+T]: def map[B](op: T ->{any.rd} B): Classified[B] ``` The pure `->{any.rd}` function arrow enforces at compile time that the mapping operation captures no escaping capabilities. You can safely map over the data or pass it to a trusted local LLM via `chat(Classified[String])`, but passing it to a cloud-facing `chat(String)` or shipping it over HTTP will fail to compile. ## 4. Scaling Beyond OpenClaw Because our security lever is the standard MCP protocol rather than application-specific code, this exact pattern generalizes. We will demonstrate the identical wrap instantly safeguarding other popular tools like Open Interpreter, Goose, and Cline. ## 5. Plugging the Browser Side-Channel A wrap that only covers standard I/O leaves the web browser open as an escape hatch—an injected agent could easily navigate to local file paths or screenshot a sensitive app and ship the raw image to a cloud API. We will debut an origin-scoped `BrowserPermission` capability (built on Playwright) that introduces `Classified[Page]` and `Classified[Image]` boundaries. We will live-extend TACIT with under 30 lines of code to render this advanced browser leak path completely uncompilable. Key Takeaways You will leave this talk with: 1. **The MCP Security Blueprint**: A concrete, repeatable recipe for wrapping and securing any MCP-compliant agent without touching its source code. 2. **A Shift from Containment to Proof**: A clear understanding of why traditional runtime sandboxing (Docker/WASM) cannot stop cognitive LLM exploits, and how information-flow control plugs the gap. 3. **Production-Ready Capabilities**: A practical framework for shipping autonomous AI tools to non-technical users without risking leaked keys or compromised environments. false https://cfp.scaladays.org/scala26/talk/KKPB93/ https://cfp.scaladays.org/scala26/talk/KKPB93/feedback/ Kesselhaus Lightning Talk 2026-10-13T12:25:00+02:00 12:25 00:05 We present DimWit, a system for writing readable numerical and machine learning code. DimWit's core feature is a trait-based implementation of the named tensor notation, which improves readability and type-safety compared to standard tensors. We illustrate how to write machine learning models using DimWit, and discuss our experience training GPT-2. scala26-99313-dimwit-tensor-programming-with-wit Benjamin MeyerMarcel Lüthi en In this session, we motivate why typed tensor computations are needed in machine learning and how named tensor notation helps us to write readable and type-safe code. We discuss the ongoing efforts in the Python community and argue that Scala already today can deliver what many Python library authors would like Python to support eventually. We present DimWit, a Scala library that implements named tensor notation as its core abstraction. We show how DimWit, which is built on top of Python’s JAX, can achieve efficiency on par with state-of-the-art libraries. We will also discuss our efforts to train GPT-2 (a 124M parameters) from scratch in Scala. We hope that this talk will show that Scala can be a better alternative to Python for expressing numerical computation and writing programs that are easier to reason about. Repository: https://github.com/dimwit-dev/dimwit false https://cfp.scaladays.org/scala26/talk/8KALEK/ https://cfp.scaladays.org/scala26/talk/8KALEK/feedback/ Kesselhaus Panel 2026-10-13T14:10:00+02:00 14:10 00:45 In this panel, we bring software practitioners and academics together to discuss language relevance in the AI era. scala26-106252-does-language-choice-even-matter-in-the-ai-era Martin OderskyNada AminArman BilgeAdam WarskiKrzysztof Romanowski en If AI generates, refines, and tests code, does our choice of programming language still matter? If an automated "software factory" can synthesize features end-to-end without (much) human supervision, shouldn't every system be written in Zig, Rust even straight to Assembly to maximize performance and minimize infrastructure costs? Or, conversely, is language choice even more critical because it directly impacts code correctness and much needed developer & agent comprehension? Host: Krzysztof Romanowski false https://cfp.scaladays.org/scala26/talk/HMWUPF/ https://cfp.scaladays.org/scala26/talk/HMWUPF/feedback/ Kesselhaus Talk 2026-10-13T15:15:00+02:00 15:15 00:30 Everyone and their dog are building permanent AI agents, but nobody is solving the real problem - how to prevent the agent from doing something it should never, ever do while preserving its general problem-solving capability. In this talk, we will introduce the CapybaraClaw - the agent built with safety in mind that gives you the peace of mind. scala26-99613-making-the-ai-agents-safe-with-scala Łukasz BiałyJakub Warchoł en In this talk, we will introduce a project shared between EPFL and VirtusLab focused on building a production-grade, permanent AI agent based on the TACIT tool developed by Martin Odersky's team. https://github.com/lampepfl/capybaraclaw The talk will be composed of: 1) Introduction: We will explain what the landscape of permanent agents (like OpenClaw) looks like, what security and safety issues exist within these projects, and how that limits their implementation in serious contexts. 2) Analysis of the problem space: we will address these weaknesses by decomposing the issue to find what the nature of the problem is - generality and elasticity vs severe limitations imposed by sandboxing, what solutions are proposed by AI companies, and finally we’ll describe how TACIT and CapybaraClaw solve whole categories of these problems by using Scala’s new capture checking facilities to enforce rules while preserving utility. 3) Deep dive: We will walk through the agent’s architecture and capabilities in detail. The focus of this part is to show how Martin Odersky’s new approach unlocks stronger safety guarantees for AI agents. 4) Summary: We’ll talk about the roadmap of the project and our goals, share links and source materials (whitepapers, CTF repos where Frontier AI was used to find exploits against TACIT, etc.). What the audience will learn: The primary benefit for attendees is the in-depth explanation of how the general and abstract system of Scala 3 capture checking and capabilities can be used productively in a use case that is much different from the usual coding. The presenters for this talk may still change! false https://cfp.scaladays.org/scala26/talk/HU3PVB/ https://cfp.scaladays.org/scala26/talk/HU3PVB/feedback/ Kesselhaus Talk 2026-10-13T16:05:00+02:00 16:05 00:30 Gain insight into how security audits are carried out on large, complex projects like Scala. Hear about how open source security advocate Open Source Technology Improvement Fund partnered with Scala maintainers to source funds, scope and manage work, and create meaningful fixes in a piece of critical software in active production. scala26-99351-advocacy-funding-and-patience-the-security-audit-of-scala Amir Montazery en This presentation will describe in detail the process of acquiring, designing, and executing a security audit on Scala. A project of this size and impact requires specific, nuanced security efforts beyond the capabilities of day-to-day operations. By introducing a skilled, experienced security team with a specific scope to the code, OSTIF created a custom security audit that created meaningful outcomes for the scala organization and project. As our ecosystem experiences unprecedented supply chain attacks and hacks, thoughts have turned to how the open source community can address and prevent exploits. First, our presenter will go over the process of creating an audit, how funding was sourced and stakeholders brought in. Then, the steps to selecting the audit team and determining the scope of work will be discussed, as well as the best security practices a project can perform especially ahead of formal security engagements. Using direct examples from our Scala audit of 2025-2026, OSTIF will show how an audit team directly collaborates with project maintainers to refine and specify their work to Scala’s needs and functions. Moving forward, the presentation will show the issues identified by the work and the steps taken by the Scala team to fix or address them as they move forward in development. Attendees will walk away with the knowledge of how a security audit works, what it does to a project in the short and long term, and a desire to contribute to Scala’s ongoing security and development. false https://cfp.scaladays.org/scala26/talk/WQVK9R/ https://cfp.scaladays.org/scala26/talk/WQVK9R/feedback/ Kesselhaus Talk 2026-10-13T16:55:00+02:00 16:55 00:30 Speed without quality is debt. This talk shows how Scala's type system, combined with a multi-layer validation pipeline (compiler, linting, property tests, mutation testing, and formal verification) helped by a concepts inventory and types generation acts as a guardrail for LLM-generated code, keeping correctness non-negotiable. scala26-99748-type-driven-ai-high-quality-scala-code-with-llm Giovanni Ruggiero en **DISCLAIMER**: This description and the above abstract have been partially generated by LLM ### Overview AI coding assistants boost development speed, but without discipline they create fragile codebases. This session presents a production-tested, spec-driven workflow that uses Scala's type system and tooling ecosystem as a verification infrastructure. The final goal is to produce correct code without accumulating technical debt. ### The Six Validation Rings The workflow is organized around six concentric rings, each catching errors the previous one cannot: - **Ring 0 - The Compiler:** Strict flags and refined types (Iron library/Smithy IDLs) encode business constraints at the type level, rejecting invalid inputs before LLM output ever runs. - **Ring 1 - Static Analysis:** Scalafix and WartRemover enforce functional programming discipline and architectural boundaries through custom rules, acting as machine-checkable preconditions for all subsequent rings. - **Ring 2 - Property-Based Testing:** ScalaCheck verifies behavior correctness. LLMs generate properties better than implementations, so properties are defined first in the specs, then the implementation is generated and verified against them. Counterexamples feed back to the LLM as targeted fixes. - **Ring 3 - Mutation Testing:** Stryker4s exposes blind spots LLMs reliably create: tests that pass the happy path but miss edge cases. A mutation score below 80% triggers reinforcement, with surviving mutants fed back as prompts. - **Ring 4 - Formal Verification:** Stainless provides mathematical proof of correctness for pure, high-stakes logic (e.g., interest calculations), verifying all possible inputs via SMT conditions. - **Ring 5 - Runtime Telemetry:** After deployment, otel4s monitors contract conformance and Daut checks temporal event sequences against state machine properties. Violations automatically feed back into Ring 2, tightening the safety net over time. A concepts inventory is added in the loop to prevent the LLM from reinventing the wheel. Further, a Type Driven Development methodology is enforced by generating first the types and then the code fulfilling them. ### Why It Matters The perceived trade-off between speed and quality is false. Scala's tools turn quality into a correctness mechanism: sealed ADTs enable exhaustiveness checks, refined types make constraints enforceable, and pure functions enable formal verification. ### What Attendees Will Learn - How to structure specs using EARS semi-formal language as a single source of truth - How to configure Scala's compiler and linting tools as automated guardrails - How to use property-based testing as a first-class generation target - How to apply mutation testing and formal verification where they add most value - How to close the loop between production runtime behavior and static verification using a workflow used daily on a 60K-line Scala codebase false https://cfp.scaladays.org/scala26/talk/JCX8GD/ https://cfp.scaladays.org/scala26/talk/JCX8GD/feedback/ Kesselhaus #ScalaDays 2026-10-13T17:45:00+02:00 17:45 00:15 Join us as we wrap up Scala Days 2026! scala26-106253-closing-session-day-2 en false https://cfp.scaladays.org/scala26/talk/TDVER9/ https://cfp.scaladays.org/scala26/talk/TDVER9/feedback/ Maschinenhaus Talk 2026-10-13T10:30:00+02:00 10:30 00:30 This is an experience report on the process and progress of improving the Standard Library, Scala Toolkit and other core Scala modules under the resources provided by the Sovereign Tech Agency. scala26-99502-report-where-are-we-going-with-the-standard-library Jamie Thompson en Depending on circumstantial changes and progress reached by October the precise contents could change. However the talk would cover the process of delivering on the project: i.e. on which areas we put focus; limitations (i.e. when you have to say no to "can't you just do X"), and hopes for future. For example beyond concrete code proposals/delivered changes, there is plenty of material to draw from such as various community proposals, an appriasal of the state of the library ecosystem, report contents for the STA (including a roadmap of ideas that may not land but were at least considered.) false https://cfp.scaladays.org/scala26/talk/H8NAKF/ https://cfp.scaladays.org/scala26/talk/H8NAKF/feedback/ Maschinenhaus Talk 2026-10-13T11:20:00+02:00 11:20 00:30 What if assertions such as `x > 0` were part of the type system? We present a prototype implementation of *logical refinement types for Scala*: types like `{x: Int | x > 0}`. In our system, refinement types are first-class: they can be nested, used as type arguments, and related by subtyping. We demonstrate the system through concrete examples. scala26-100165-first-class-logical-refinement-types-for-scala Matt Bovel en This talk introduces *logical refinement types* for Scala 3 as a first-class language feature, backed by a working compiler prototype. A refinement type refines a base type `T` with a logical predicate `p(x)`, written `{x: T with p(x)}`: the set of values `x: T` for which `p(x)` holds. For example, `{x: Int with x > 0}` is the type of positive integers and `{x: List[Int] with x.nonEmpty}` the type of non-empty lists. The idea appears in many languages under different names: [*refinement types* in Liquid Haskell](https://ucsd-progsys.github.io/liquidhaskell-tutorial/Tutorial_01_Introduction.html), [*boolean refinement types* in F\*](https://fstar-lang.org/tutorial/book/part1/part1_getting_off_the_ground.html#boolean-refinement-types), [*subset types* in Dafny](https://dafny.org/latest/DafnyRef/DafnyRef#sec-subset-types), and [*subtypes* in Lean](https://lean-lang.org/doc/reference/latest/Basic-Types/Subtypes/). We call them *logical refinement types*, or *refinement types* for short, to distinguish them from Scala's existing [*refined types*](https://scala-lang.org/files/archive/spec/3.4/03-types.html#refined-types), which add members to a type rather than constrain its values with a predicate. In short, refinement types move assertions into the type system. For the compiler to accept `e: {x: T with p(x)}`, it must prove that `p(e)` holds for every `e: T`, so `assert(p(e))` can never fail at runtime. This buys three things: 1. **No runtime cost, total guarantees.** Predicates are checked at compile time, so there is no runtime overhead, and the property holds for *all* values rather than only those a test happens to exercise. 2. **Composability.** Refinement types are ordinary types, so they nest without ceremony: `{x: Int with x > 0} => String` is a function that rejects non-positive inputs, and `List[{x: Int with x > 0}]` a list of positive integers. 3. **Self-documenting APIs.** Pre- and post-conditions live in the signature instead of scattered `require`/`assert` calls, which also improves IDE support and documentation. ### Syntax and Predicate Language `{x: T with p(x)}` is the *long form*. It introduces an explicit binder `x` for the value being refined, which is useful when no name is otherwise available, for example in type aliases or return types: ```scala type Pos = {x: Int with x > 0} def fill(n: Pos, v: Int): {res: List[Int] with res.size == n} = ??? ``` When the value already has a name, as in a `val` or a parameter, the binder can be dropped. This *short form* reuses the existing name and desugars to the long form: ```scala val x: Int with x > 0 // desugars to: val x: {x: Int with x > 0} ``` Predicates also have to be something the compiler can reason about statically, so they must be *pure* and *terminating*. Concretely, the predicate language is a fragment of Scala: constants, stable identifiers, field selections over `val` fields, term and type applications, and constructors of case classes without initializers. Functions called from predicates are assumed pure and terminating; the prototype does not yet enforce this, so for now it is the programmer's responsibility. ### Selfification Scala already has precise types it usually throws away: the literal `42` has singleton type `42`, but `val x = 42` widens to `Int` unless annotated as `val x: 42 = 42`. Refinement types follow the same rule: they are *not* inferred from terms by default. This keeps the types Scala assigns unchanged, preserving source compatibility and avoiding a proliferation of fine-grained types that could hurt performance. Instead, the refinement type is written explicitly where it is wanted. When one is expected, the compiler tries to *selfify* the expression: it gives `e: T` the type `{x: T with x == e}`, lifting the expression into the type as long as it is a valid predicate. ```scala val x: (Int with x == 42) = 42 val y: (Int with y == n + 2) = n + 2 ``` ### Runtime checks When a property cannot be established statically, it can be recovered at runtime through pattern matching: ```scala type ID = {s: String with s.matches(idRegex)} "12e7-e89b-12d3" match case _: ID => // s matches idRegex case _ => // s does not match idRegex ``` When the program should simply fail if the predicate does not hold, the `runtimeChecked` method performs a dynamic check and throws otherwise. As elsewhere in Scala, matching on erased type arguments is not supported: a `List[ID]` or an `ID => String` cannot be matched directly. For collections and similar cases, a custom [`TypeTest`](https://docs.scala-lang.org/scala3/reference/other-new-features/type-test.html) lifts the restriction. ### Subtyping The interesting question is how to decide whether one refinement type is a subtype of another. By definition, `{x: T with p(x)}` is a subtype of `{y: S with q(y)}` when `T <: S` and the predicates are related by implication: `p(x)` must imply `q(x)` for all `x`. The system has to establish both conditions. Rather than calling out to an external SMT solver, we built a lightweight solver into the compiler, tuned for the cases that come up in everyday code. It combines three techniques: *equality reasoning*, using the E-Graph data structure to compute congruence closure (from `v == a` and `a > 3` it derives `v > 3`); *normalization*, putting arithmetic into canonical form so that `x + 3 * y` and `2 * y + x + y` are seen as equal; and *inlining of known refinements and definitions*, so that a value of type `Int with y == x + 1` (or even a plain `val y: Int = x + 1`) contributes `y == x + 1` to the reasoning. Refinement types also interoperate with the rest of the type system. For instance, the literal type `1` is a subtype of `{x: Int with x == 1}`, and hence of `{x: Int with x > 0}`. ### Case studies The heart of the talk is a tour of what refinement types can express. We present a few examples below. **Pre- and post-conditions in a signature.** The simplest use is constraining inputs. A color channel is a byte-ranged integer, and stating that once removes a whole class of bounds checks downstream: ```scala type ChannelValue = {v: Int with 0 <= v && v < 256} def rgb(r: ChannelValue, g: ChannelValue, b: ChannelValue): Int ``` **Length-indexed collections.** Tracking a collection's size in its type turns length mismatches into compile errors. Here `concat` and `zip` carry exact length relations, and the compiler chains them to verify the final length on its own: ```scala type Vec[T] object Vec: def fill[T](n: Int, v: T): {r: Vec[T] with r.len == n} = ??? extension [T](a: Vec[T]) def len: Int = ??? def concat(b: Vec[T]): {r: Vec[T] with r.len == a.len + b.len} = ??? def zip[S](b: Vec[S] with b.len == a.len): {r: Vec[(T, S)] with r.len == a.len} = ??? def example(n: Int, m: Int): {r: Vec[(String, Int)] with r.len == m + n} = val v1 = Vec.fill(n, 0) val v2 = Vec.fill(m, 1) val v3 = v1.concat(v2) // len == n + m Vec.fill(m + n, "").zip(v3) // checked: m + n == n + m ``` **Predicates as a dispatch key.** Because refinement types are real types, they participate in overload resolution. This for example allows us to ship a fast path that is only valid under a precondition, and let the type checker pick it when the precondition is known: ```scala def min(l: List[Int] with l.isSorted): Int = l.head // O(1) def min(l: List[Int]): Int = l.min // O(n) def example(l: List[Int] with l.isSorted): Int = min(l) // resolves to the O(1) overload ``` **A verified memoized Fibonacci.** Finally, we scale up to a more verification-flavored example: a memo table whose values are tied to the keys by a predicate, used to prove that a memoized `fib` returns exactly the same results as the reference definition: ```scala case class DepMap[K, V](p: (K, V) => Boolean): def put(n: K, v: V with p(n, v)): Unit = ??? def get(n: K): Option[{res: V with p(n, res)}] = ??? def fib(n: Int): {r: Int with r == (if n <= 1 then 1 else fib(n - 1) + fib(n - 2))} = if n <= 1 then 1 else fib(n - 1) + fib(n - 2) val cache: (DepMap[Int, Int] with cache == DepMap[Int, Int]((k, v) => v == fib(k))) = DepMap[Int, Int]((k, v) => v == fib(k)) def fibMemo(n: Int): {res: Int with res == fib(n)} = cache.get(n) match case Some(res) => res case None => val res: (Int with res == fib(n)) = if n <= 1 then 1 else fibMemo(n - 1) + fibMemo(n - 2) cache.put(n, res) res ``` ### Related Work In the Scala ecosystem, libraries such as [Refined](https://github.com/fthomas/refined) and [Iron](https://github.com/Iltotore/iron) offer user-level encodings of refinement types using opaque type aliases and implicit evidence. The talk will compare our approach with these libraries, showing how integrating the checks directly into the compiler increases expressiveness, reduces boilerplate, and improves performance. false https://cfp.scaladays.org/scala26/talk/X9YKXK/ https://cfp.scaladays.org/scala26/talk/X9YKXK/feedback/ Maschinenhaus Talk 2026-10-13T15:15:00+02:00 15:15 00:30 This talk will explore the intersection of OSS communities and the integration of generative and agentic AI in software development practices. This talk will go over emerging tensions for OSS communities and offer tools for projects to support and protect their members. scala26-106618-oss-ai-how-to-support-your-project-community Hana Frluckaj en false https://cfp.scaladays.org/scala26/talk/TTXSYQ/ https://cfp.scaladays.org/scala26/talk/TTXSYQ/feedback/ Maschinenhaus Talk 2026-10-13T16:05:00+02:00 16:05 00:30 Learn how to accelerate Scala code by orders of magnitude with Cyfra. There are many libraries that give you access to low-level GPU APIs, but a high-level, functional one is a different story. That’s why we created the Cyfra GPGPU framework. In this talk, we’ll demonstrate how to use it to build high-performance GPU applications with Scala. scala26-99741-cyfra-scala-on-gpu Szymon RodziewiczMarcin Złakowski en In this talk, we will show how to build high-performance Scala GPU applications with Cyfra. First, we will introduce the audience to the current landscape of GPU programming and explain our philosophy. Then, we will dive into our model of type-safe data pipelines and memory management. To complete the picture, we will also showcase a set of real-world applications, including an end-to-end LLM inference engine, written entirely in Scala. false https://cfp.scaladays.org/scala26/talk/8GCRBN/ https://cfp.scaladays.org/scala26/talk/8GCRBN/feedback/ Maschinenhaus Talk 2026-10-13T16:55:00+02:00 16:55 00:30 We are currently working on Metals 2, which is a new indexing and compilation approach, designed to make indexing as fast as possible and ensure the editor remains functional even if parts of the project fail to compile. Thanks to this even while working on large monorepos it should be possible to quickly set up your editor. scala26-99509-metals-reimagined-lsp-in-the-age-of-llms Tomasz Godzik en Metals is the Scala and Java Language Server, providing IDE features within editors such as Visual Studio Code, Cursor, Zed, and Helix. This makes it essential for anyone looking to use new agentic tools. Many companies are now utilizing LLM trends to boost developer performance, but a major challenge has has been that Metals becomes less efficient as codebases scale—a common issue in large organizations. Metals 2 is a new indexing and compilation approach, designed to make indexing as fast as possible and ensure the codebase remains functional even if parts of the project fail to compile. Applying this to both Scala and Java code, Metals 2 aims to become the premier JVM language server. We are currently cooperating with multiple large monorepos testing and further enriching this approach. Let’s explore how this can enhance developer workflow to show the Scala developers that tooling can finally be great. false https://cfp.scaladays.org/scala26/talk/8NF7WU/ https://cfp.scaladays.org/scala26/talk/8NF7WU/feedback/ Palais Atelier Talk 2026-10-13T10:30:00+02:00 10:30 00:30 Debugging in Scala can be frustrating, but it doesn’t have to be. Discover how IntelliJ IDEA’s debugger thanks to features like conditional breakpoints and smart logging, can help you pinpoint bugs faster and with less hassle. Leave with practical tips to debug smarter, not harder. scala26-99214-mastering-intellij-idea-s-debugger-for-scala-development Maciej Gorywoda en Debugging sounds like a very straightforward task. You place breakpoints, run the program, and see where it stops and what values the fields hold at that point. When it’s not enough, you make yourself a big warm mug of coffee, sprinkle the code with println statements, and mentally prepare for a day of reading logs and re-running the program over and over until it starts to make sense. But if you have the right tools at your disposal, debugging in Scala does not have to be such a grueling task. This talk explores practical techniques and underused features of IntelliJ IDEA’s debugger to help you pinpoint bugs with precision, even in complex codebases. We will cover, among others, conditional breakpoints, log expressions, the call stack, the println debugger, and unsuspended breakpoints for logging. You will leave this talk with actionable insights to improve your debugging experience and reduce reliance on verbose log statements. false https://cfp.scaladays.org/scala26/talk/K7ZLQH/ https://cfp.scaladays.org/scala26/talk/K7ZLQH/feedback/ Palais Atelier Talk 2026-10-13T11:20:00+02:00 11:20 00:30 Interpreting lambda calculus is simple but slow. Using multi-stage metaprogramming, we built a JIT that compiles each program to native JVM code at load time, running 2–10x faster than existing interpreters – including heavily optimized Rust and Haskell implementations. The surprising part: staging resulted in remarkably little code. scala26-100197-blazing-fast-lambda-calculus-via-metaprogramming Alex Nemish en Many systems ship small programs in a tiny language based on lambda calculus – functions, function calls, a handful of built-in operations, and constants – and run them with an interpreter. We replaced the interpreter with a JIT that translates each program into native JVM code as it loads: a lambda becomes a JVM lambda, an application becomes a real function call, and built-ins and constants map onto efficient runtime primitives. What I find most compelling is how little code it took: multi-stage metaprogramming let us turn an interpreter into a compiler with surprisingly little code, which says a lot about how powerful the technique is. I'll walk through the staging approach, the benchmark results against existing interpreters, and the subtle pitfalls of JIT-compiling an untyped language while preserving exact evaluation semantics – a practical tour of runtime code generation and metaprogramming on the JVM. false https://cfp.scaladays.org/scala26/talk/SX7FTM/ https://cfp.scaladays.org/scala26/talk/SX7FTM/feedback/ Palais Atelier Talk 2026-10-13T15:15:00+02:00 15:15 00:30 You will learn about how to measure test coverage of your Scala codebase with Scoverage, the Scala 3 coverage tool. After learning the basics, we will dive deeper into how it is implemented, and talk about the hardening work done by the Scala Center to make the feature robust and reliable in interaction with the rest of the language features. scala26-99257-scoverage-test-coverage-for-the-scala-codebases Anatolii Kmetiuk en Code coverage is a critical feature for robust quality assurance at the industry. It sounds simple: mark which lines ran. In Scala 3, Scoverage is a compiler feature: it rewrites typed trees, inserts tracking probes, and then hands the modified tree to every later compiler phase. That makes it available out-of-the-box for all Scala users with a simple compiler flag. Tight coupling with the compiler itself, though, poses a challenge in making it work with all compiler features. This talk has a dual purpose. First, it is a guide to get started using coverage in your codebase. You will walk out of this 30-min talk having a useful skill of measuring how well your tests cover your code, thus contributing to reliability and robustness of your work. Second, it is a technical deep dive into how coverage works under the hood, and what challenges we encountered making it work well. Coverage sits fairly early in the pipeline of compiler phases, and it modifies the trees heavily with instrumentation. Frequently, this breaks assumptions for the downstream phases that are responsible for all the numerous Scala 3 features. Examples include instrumentation interacting with erasure, singleton and wildcard types, capture checking, pattern matching, tail-recursion and infinite-loop warnings, constructor calls, parameterless methods, closures, and JVM method-size limits. These are a lot of pieces interacting in complex ways. To make coverage work robustly, it is necessary to track, prioritize and fix breakages in a systematic way. In this talk, we will explore the process we use for that, as well as give some highlights of the typical breakages we encounter. So the second purpose of this talk is to give a glimpse to a curious-minded engineer into the compiler internals. An industry practitioner will leave with a deep understanding not only of how to use the coverage feature, but also how it works under the hood. And for someone working on the compiler or just curious about how Scala works, it is a great opportunity to learn more about the compiler itself. false https://cfp.scaladays.org/scala26/talk/FTJSQF/ https://cfp.scaladays.org/scala26/talk/FTJSQF/feedback/ Palais Atelier Talk 2026-10-13T16:05:00+02:00 16:05 00:30 You deploy a harmless-looking change… and production starts failing: consumers crashing, events rejected. What went wrong? In this talk, we demystify message compatibility across events and APIs, showing how to evolve schemas safely without breaking your systems. scala26-99884-stop-breaking-production-schema-evolution-demystified Jan-Pieter van den Heuvel en This session explores how and why message compatibility breaks in real-world systems: across events, commands, APIs, and persisted state. We’ll clarify backward, forward, and full compatibility, and map them to concrete schema evolution rules (what you can safely add, remove, or change, and what you can’t). You’ll see practical rollout strategies (consumer-first vs. producer-first), and how mistakes lead to subtle, production-breaking issues. We’ll also discuss the trade-offs and decisions you face when message consumption fails in production. Finally, we’ll compare JSON, Protobuf, and Avro through the lens of compatibility guarantees, and demonstrate how a schema registry and code generation help enforce contracts at scale. You’ll leave with actionable patterns and mental models to evolve distributed systems confidently without breaking production. false https://cfp.scaladays.org/scala26/talk/RBXTYA/ https://cfp.scaladays.org/scala26/talk/RBXTYA/feedback/ Palais Atelier Talk 2026-10-13T16:55:00+02:00 16:55 00:30 We will present our ongoing work to bridge between Scala 3 (& Kotlin) and Python 3 using GraalVM. We will explain how the interoperability was designed; how type hints map to Scala 3's type system, how other Python 3 concepts translate to Scala, and our the progress to publish python wheels to close. scala26-99958-bridging-between-scala-python-with-graalvm Hamza Remmal en Thanks to its rich ecosystem of libraries, Python 3 has become the most widely used programming language over the last few years. In this session, we will present our ongoing work to bridge between Scala 3 and Python 3 using GraalVM. We will introduce the architecture and key decisions of our design and demonstrate how Python 3 code can be safely used seamlessly within a Scala 3 project. The audience will learn how Python type hints are represented within Scala and how other Python concepts are adapted to Scala. A key part of the ongoing effort is making popular Python libraries ready and available to be used within the JVM ecosystem using our tool. We will therefore report the current status of the ongoing work to publish the metadata necessary for the libraries to be used. The talk will also include practical demonstrations showing how python source code, and how the mentioned libraries, can be integrated with minimal boilerplate within Scala 3 projects. At the end of the talk, the audience should be able to use all of the presented material and be able to build cross-language projects with all of their favourite Python libraries within their Scala 3 projects. false https://cfp.scaladays.org/scala26/talk/HV9UPQ/ https://cfp.scaladays.org/scala26/talk/HV9UPQ/feedback/ Frannz Salon: Lab 1 Interactive labs 2026-10-13T11:00:00+02:00 11:00 02:00 Build and ship a production-ready microservice in direct-style Scala 3: no Futures, no IO monads. Set up an HTTP API with Tapir, concurrency and resilience with Ox, a type-safe SQL layer, and an sttp client, with AI assistance throughout. Type-safe, Loom-powered, and refreshingly simple Scala. scala26-99979-build-a-production-service-with-virtuslab-scala-stack-and-ai Piotr Janczyk en This lab is a hands-on follow-up to the talk "VirtusLab Scala Stack — back to the roots." The talk argues for direct-style Scala, in the lab, you write it. Over two hours you'll build a working microservice in Scala 3 without reaching for Futures or IO monads. The code reads as plain, sequential Scala, even though it's backed by a strong type system, automatic resource handling, and Java's virtual threads. We start from a prepared project, so setup takes a few minutes rather than half the session. From there you'll add an HTTP API with Tapir and its generated OpenAPI docs, manage concurrency, timeouts, retries, resource safety, and error handling with Ox, read and write data through a typed SQL library (Parlance), and make outbound calls with sttp. You'll also see how AI coding assistants, guided by VirtusLab's open-source Scala skills, speed up writing idiomatic direct-style code. We finish with something most teams actually face: taking a piece of Future-based code and moving it to direct style, showing that you can migrate gradually. The goal of this session is to show a lower-effort way into Scala for people who don't need full power of IO monads: less to learn, syntax that's familiar from other languages, and code that current AI tools handle well, while keeping Scala's type safety. After this workshop you will be able to start and structure a direct-style service yourself, with a clearer sense of when the style fits. The lab suits Scala developers curious about direct style, and anyone considering Scala 3 for backend work. --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/PRW8FG/ https://cfp.scaladays.org/scala26/talk/PRW8FG/feedback/ Frannz Salon: Lab 2 Interactive labs 2026-10-13T11:00:00+02:00 11:00 02:00 Learn about Cats Effect and FS2 while building a collaborative webapp with Calico! In this lab you will build an interactive widget for a webapp. Along the way we will learn about the IO, Resource, Stream, and Signal monads, and how the Typelevel stack can be used to make frontend applications. scala26-99651-build-a-webapp-with-cats-effect-and-fs2 Arman Bilge en Calico is a UI library for building interactive web applications using Cats Effect and FS2. This lab uses Calico as a learning aid to introduce attendees to the Typelevel stack and functional programming. By deploying Cats Effect and FS2 programs in an interactive webapp, they will get a real-time feedback loop to experiment with how different features of these libraries work in practice. Building frontend applications is also a case study of the powers of different kinds of monads: IO, Resource, Stream, and Signal all play important roles in Calico. It also helps develop a more nuanced view of concurrency, by considering the role of fibers in a single-threaded frontend application. We will start by building a "hello world" widget together as an example. This is when we will cover the core concepts. Then, attendees will work in pairs to design and implement an interactive widgets using Calico. To make their component interactive, they will have to reach for different features of Cats Effect and FS2. We will assemble all of these widgets into a single webapp. I ran a version of this lab during the Typelevel Meetup last year. Here was the product: https://www.armanbilge.com/lausanne-meetup-aug-2025/ Because attendees will work on their own widgets in pairs, I think this lab will simultaneously be able to serve two audiences: (1) Attendees familiar with the Typelevel stack and want to have a taste of how it can be used to create frontend webapps with the Calico library. (2) Attendees new to Typelevel and functional programming who will get a feel for the capabilities of this paradigm via an interactive sandbox. --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/Y7ZCVR/ https://cfp.scaladays.org/scala26/talk/Y7ZCVR/feedback/ Frannz Salon: Lab 3 Interactive labs 2026-10-13T11:00:00+02:00 11:00 02:00 Laminar is a Scala.js-first approach to reactive UI for the web, combining declarative presentation with logic for how to make updates based on events or other state changes. Beyond basics, lets also explore interop with JS libraries, and even concerns such as code organisation, and effective error handling practises. scala26-99512-reactive-ui-with-laminar Jamie Thompson en This lab is all about becoming effective with the Laminar library for Scala.js: avoiding spaghetti code, managing events, and asynchronous communication with the backend. We would also consider concerns such as targeted updates to dynamic elements. Example of interop can be with jQuery widgets. This would be project based. Probably covering some sort of CRUD application with form validation, and asynchronous search. (Perhaps it can be a more whimsical domain for entertainment purposes). I have 2 years professional experience using Laminar to build business applications. --- This session will not be livestreamed or recorded. false https://cfp.scaladays.org/scala26/talk/HM87YG/ https://cfp.scaladays.org/scala26/talk/HM87YG/feedback/