Blog

I recently wrote about keeping Scala simple. That’s something you have to work at. Let me explain.

While packing up to move house I came across my undergrad vector calculus notes. Although I, sadly, don’t remember the definitions of div, grad, and curl I do remember that course as marking a turning point in my academic career.

An upsert means inserting a row into a database if it doesn’t already exist, or updating the row if it does exist. The Slick database library knows how to do upserts. This posts takes a look at the built-in support, and gives an example of what you can do if you need to roll your own upsert logic.

This is part of a series on Slick, for material in or being added to Essential Slick.

Hi everyone,

We’ve had a heatwave in London this week with highs of over 30 Celsius (unusually toasty for the rainy UK). To celebrate, let’s pull out our deckchairs, place our knotted handkerchiefs on our heads, and dive into the latest news from the Underscore Newsletter.

This month we’re focusing on conferences: Scala Exchange is just around the corner, the videos from Scala Days are out, and we’re doing some advanced Scala training at Scala World. Plus some blog posts about cats and robots… this is the internet, after all!

In this post I want to explore the design of a type class solving a problem that came up repeatedly in my current project. It’s fairly general, so rather than diving into the details of the project, I’ll start with a few simple examples:

• integer multiplication is annihilated by zero, in that once zero is introduced the result is always zero;
• set intersection is annihilated by the empty set, in that once the empty set is introduced the result is always the empty set; and
• field dereferencing using the “null-safe” ?. operator in Kotlin and Coffeescript is annihilated by null, in that once a null is introduced the result is always null.

You don’t have to venture far to find people arguing that Scala is a complex language, or that Scala needs to be more opinionated. Luckily I have plenty of opinions, specifically about how to make Scala simpler, and this is something I’ve been espousing in my recent talks at Scala Days SF and Amsterdam (slides here).

The problem with talking about simplicity is that it becomes one of those things like “good art” that’s defined as “I know it when I see it.” This provides no guidance. We need more precision. In this blog post I want to discuss complexity from three different angles and give concrete recommendations for creating simple Scala code.