Saturday, February 13, 2021
The focus of the talk is to emphasize the importance of algebraic thinking when designing pure functional domain models. The talk begins with the definition of an algebra as consisting of a carrier type, a set of operations/functions and a set of laws on those operations. Using examples from the standard library, the talk shows how thinking of abstractions in terms of its algebra is more intuitive than discussing its operational semantics. The talk also discusses the virtues of parametricity and compositionality in designing proper algebras. Algebras are compositional and help build larger algebras out of smaller ones. We start with base level types available in standard libraries and compose larger programs out of them. We take a real life use case for a domain model and illustrate how we can define the entire model using the power of algebraic composition of the various types. We talk about how to model side-effects as pure abstractions using algebraic effects. At no point we will talk about implementations. At the end of the talk we will have a working model built completely out of the underlying algebra of the domain language.
GitBucket is an open source self-hosting git server written in Scala. It's has been 8 years since I started development in 2013 and got about 8,300 stars on GitHub. As you can imagine, updating such a large application regularly for a long time as a personal project is really challenging. In this talk, in addition to introducing to GitBucket and its architecture, I would like to talk about how I have updated GitBucket regularly and efficiently until now and how Scala has helped it.
Recursion schemes are a topic that often come up in conversations with experienced, knowledgeable developers. For the longest time, I’d just nod and smile and pretend I knew what was going on.
The purpose of this talk is to help people in the same situation. Recursion schemes are far less scary and confusing than the mystique that surrounds them suggests, and this talk attempts to prove it.
We’ll start from first principles and refactor our way to proper recursion schemes, discovering and explaining all the necessary concepts as we go along.
By the end of the talk, attendants should have all the tools they need to understand recursion schemes, and be able to explore the more esoteric ones on their own.
Scala 3 is just around the corner. Both EPFL and the broader community have put a lot of work into making this Scala release a success. In this talk, I will outline some of the history behind Scala 3 and what steps we took in the Typelevel ecosystem to get ready for Scala 3, and keep up with its development.
The CLI of coursier, cs, offers a convenient way to install both JVMs and Scala applications. cs itself is a native binary with no dependencies, is available on all major platforms, and can get you started with installing and running Scala tools in minutes. It can be useful to setup your local development environment, but also from scripts, or on your CI.
Until now, the first concern of cs has been ease-of-use. But what about reproducibility? cs rests on the core of coursier, and reproducibility / “purity” has always been a central concern in the core modules of coursier. Could this help recovering reproducibility in the higher level features of the coursier CLI?
In this talk, we are going to first showcase what cs, the coursier CLI, can do, and how it can be useful on your local machine, from scripts, and on your CI. Then we’ll discuss how we can make invocations of cs reproducible and what newer options are available to help for that.
Don’t ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we’re at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That’s exactly what property-based testing has to offer. I’ll show how to get started with this kind of testing in Scala, using using ScalaTest and ScalaCheck. But isn’t it all too good to be true, surely there’s some fine print? Of course there is. I’ll cover that as well.
I am the type of person who learns new technologies on the job, so I needed a project to explore Scala 3 in-depth. More or less at the same time, we’ve decided to make our apartment just a bit smarter, and I thought this is a perfect occasion to play with Scala 3 (and many other toys).
My plan was simple: start with existing, stable integration: Home Assistant running on Raspberry PI, explore and use Scala on top of that.
Home Assistant has a fantastic ecosystem that reminds me of one we have in Scala. Everything I’ve done with Scala I could have achieved easier and faster with built-in automation, Node-Red or Python but this project was all about learning and fun!
So let me show how it works and how new features from Scala 3 can improve even such a small project.
At Inpher, we have built a domain specific language (DSL) for modelling privacy preserving computations. This DSL is targeted at cryptographers who are not necessarily familiar with Scala at all, yet it is written entirely in Scala 3! In this talk, I will present some of Scala 3's new features that were used to make the DSL powerful while keeping it very user friendly. I will share some experiences we've had as early adopters of Dotty, as well as some lessons learned while introducing the DSL to complete newcomers of the language.
For almost four years now I work professionally on the Android client of an end-to-end encrypted messenger, in Scala. In Android we deal a lot with events coming from many sources: the user, the backend, the Android OS itself… The code we write has to be very reactive - and it should also be concise and able to process all those events concurrently to squeeze all we can from limited resources. Scala should thrive under those conditions. And yet, it’s almost non-existent. People who still write it are forced to use old versions of libraries, on top of an old version of the language itself, to modify Gradle scripts, and basically to jump through countless loopholes which shouldn’t exist. Most of those people already either moved to other market niches… or to other programming languages.
In this talk, I want to outline how we ended up in this weird position. What attempts were made in the past to introduce Scala on Android, and how they failed. What hacks and concessions are needed in the present to still be able to write Scala on Android. But also I want to tell you about recent developments that give me a reason to believe that the future might be better. It will require a lot of effort, though, and so I want to inspire you to help me.
On the practical side, during this talk, you will learn how to build your own Android apps in Scala - in both versions: using the current (outdated) framework, and the new (experimental) one.
MUnit is a testing library for Scala built. “Another one?!”, you may say? In this talk we’ll explore together the most notable features of MUnit and see what makes this little library unique! Via a series of live code examples, we’ll answers questions like: - Why does MUnit not have a DSL? - How do we integrate MUnit with other libraries? - How can MUnit help dealing with flaky tests?
At the end the presentation, MUnit may become your new favorite testing library!
When Scala Native was first announced it opened many new possibilities for multiple different areas of computing. For serverless and tooling it promised instant startup and low memory usage. At the same time, for low-level programming it offers interoperability with a multitude of C libraries.
Last year the Scala Center committed to taking care of this project, adding support for the latest Scala releases and extending it with new features. Thanks to cooperation between VirtusLab, the Scala Center and community contributors, Scala Native is now back on track with high hopes for a small revolution in the Scala ecosystem. This talk covers my experience of working on the Scala Native team, and shares what I have learned about Scala and the native ecosystem, as these two worlds come together.
During the talk we will discuss: * working with compiler plugins * how Scala Native differs from alternative solutions * how native is different from the JVM * LLVM and how Scala Native uses it * how Scala Native’s design decisions influenced its advantages and limitations
Additionally I will discuss the current status of Scala Native as well as its roadmap in 2021.
Have you always wanted amazing compile-time features in your API, but been afraid of the Scala 2 macro syntax? Have no fear, Scala 3 is here! Scala 3 provides a rich set of features that negate the need for most macros and provide an incredible toolset for APis that are easy to maintain. We'll look at using inline methods, tuples and derived code to create performant AND flexible APIs, as well as prototype implementations from GPU + serialization use cases.
A quick agenda: Improving performance with Inline Deriving code at compile time & working with Tuples Writing good error messages w/ inline When not to inline
In the first Scala Love online conference on April 17, 2020, I gave a talk entitled Understanding Scala’s Type System. That talk mostly covered aspects common to Scala 2 and 3, it did cover union and intersection types. This talk is a continuation of that talk. It covers more advanced aspects of the type system, mostly new forms of types that are being introduced in Scala 3.
Implicits are one of Scala's most powerful features. This single mechanism can be used in various idiomatic ways to implement a number of capabilities, like implicit conversions. One of the biggest changes in Scala 3 is a reworking of implicits to introduce new constructs that make the capabilities more intuitive, with less emphasis on a single mechanism.
The new constructs include extension methods, a new way to write type classes, given instances with using clauses, given imports, and new implicit conversions. I'll discuss how to use them, how they contrast with Scala 2 idioms, and how Scala will gradually transition to them, supporting both implicits alongside the new features for a while.
Let’s face it: if you want to quickly hack a script for use by somebody else, Scala is rarely the first choice. Unlike Bash and Python, the essential dependencies (Java Virtual Machine, Ammonite) are usually missing on the target operating systems. This leaves you with a dilemma: should you instruct your users to install the missing bits or should you ship something, that they’ll run instantly (Bash, Python)? I think this is one of the reasons, why most of the common helper scripts is not being written in Scala. That is a shame. TSK - The Scripting Kit (https://github.com/tsk-tsk/tsk-tsk) aims to change that. With TSK you can create a Scala script that is instantly self-installable-and-executable after you save it and set the executable bit. You achieve that by prepending your Scala code with a special preamble, which consists of shell commands disguised as a Scala comment. You end up with something that works on multiple systems from the get-go and is nicely editable with IDEs at the same time. A scripting nirvana!