Scala arrived in 2004 as Martin Odersky’s argument that object-oriented and functional programming belong in one language on the JVM. The argument worked twice, on two different audiences, and that’s where the split began.

The first audience came from Java. Twitter’s very public migration made the loudest case in 2009: they wanted the JVM’s performance and libraries without Java’s ceremony, and Scala delivered exactly that. Case classes replaced forty-line bean definitions, and collections became something you transform rather than loop over. Everything still compiled to bytecode the ops team already knew how to run. Much of the JVM’s data infrastructure grew up in this dialect: Spark still lives there, and Kafka’s core began there, though Kafka has been shedding its Scala for years. It’s the first function above: direct, effectful, recognisably Java-shaped underneath.

The second audience arrived from the opposite direction. Functional programmers, many with Haskell in their history, saw a typed language on an industrial runtime and started building the discipline they were used to: effects tracked by the compiler, and errors that travel as ordinary values instead of thrown exceptions. Out of that came the Typelevel stack (Cats, then Cats Effect, then the http4s and doobie family that carries Part IV of this book) and later ZIO, a parallel ecosystem with the same conviction and different ergonomics. That’s the second function above: nothing happens when you call it; it builds a description of a program, and the runtime executes that description at the edge of the application.

The language supports both because it was designed to. Odersky describes Scala as a staircase you can stop climbing at any step. What the design didn’t anticipate is that teams camp on a step and interview for it.

There are "better Java" shops, very often Play Framework codebases, where an IO in a pull request reads as showing off. There are functional shops where a bare side effect reads as a defect. Both kinds ship real software and have done for years.

Picture the same three-line change, a discount recomputed on invoice totals, opened as a pull request in both codebases. In the first it’s approved in minutes with a nitpick about naming. In the second, the review asks why the function reaches into the database directly instead of returning a description of the work, and what happens when two discounts land at once. Neither review is wrong. They’re reading different languages that happen to share a compiler.

So this book refuses the usual move of anointing one dialect. The route instead: Part I teaches Scala as a better Java, honestly and without apology, because that’s the working on-ramp for a Java developer and it’s real Scala, not a training-wheels dialect. Part II covers the type-driven middle ground both cultures share, where the language stops being a nicer syntax and starts being a better tool. Part III builds the second Scala from first principles, so that when IO arrives you’ll have invented most of it yourself and can judge it on results. Part IV puts the whole thing in production, and includes a chapter on Play precisely because the first dialect runs a large fraction of the industry’s Scala and pretending otherwise helps nobody.

The honest pitch for a Java developer comes down to how much work the compiler does for you.

In Java, a large class of correctness lives in convention: this reference is never null (says a comment), this switch covers every case (until someone adds an enum constant), this object is immutable (as long as nobody calls that one setter). Scala’s habit, and the running theme of this book, is to move those promises into types, where breaking them stops compilation instead of paging whoever’s on call. Chapter 4 does it to null. Chapter 7 does it to "did we handle every case". By Part III the same trick applies to "what side effects can this function have", which is the promise Java can’t even write down.

Meanwhile you lose nothing about the platform you rely on. Scala compiles to JVM bytecode and calls any Java library directly, so your profilers and your hard-won GC folklore keep working. Your Postgres driver doesn’t know the difference, and neither does your deployment pipeline. This matters more than any language feature: adopting Scala is a language decision, and only a language decision, on a platform you already trust.

And Scala 3, the only Scala this book teaches, is a calmer language than its folklore. The reputation for inscrutable code was earned mostly by Scala 2-era implicits and a community phase involving custom operators that looked like modem line noise. Scala 3 removed or tamed the worst of it, and the libraries this book teaches have all completed their move to it. The honest exception is the big-data corner: Spark still builds against Scala 2.13, which matters if your future is data engineering and not at all if it’s services. Either way, you’re arriving after the turbulence, which is a genuinely good time to arrive, well done you.

You should also hear the costs from us rather than discover them.

The hiring pool is smaller than Java’s by an order of magnitude, and the two-dialect split cuts it again: a "Scala developer" who has only ever written Play services will need weeks to be productive in a Typelevel codebase, and vice versa. This book exists partly to shrink those weeks, but no book removes them.

The ecosystem carries scars. Lightbend relicensed Akka out from under the community in 2022, and the fork (Pekko) is what Play now runs on; chapter 21 tells that story properly. Several libraries the community treats as production-standard have spent years shy of a 1.0 version number. None of this is disqualifying, and the community that remains is unusually senior and unusually helpful, but the JVM’s boring stability lives in Java-land, and Scala trades some of it for reach.

The compiler is slower than Java’s, too. It’s doing more work, and on a large codebase the difference is real. Incremental compilation and the tooling this book uses keep it comfortable at the scale we’ll work at, but the folklore about Scala build times was earned honestly, and the IDE story was rough for years before Metals and IntelliJ’s Scala plugin matured. It’s fine now. It wasn’t always.

Where does that leave the decision? Scala pays off where correctness is expensive to get wrong: money, bookings, anything concurrent, anything where a 3am incident costs more than a slower onboarding. If your organisation needs to hire forty juniors a quarter, write Java. If it needs six people to run something correct and concurrent, keep reading.

Abstract examples teach abstractions; this book builds one thing and keeps building it. Fully Booked is a restaurant table-reservation service, chosen because you already understand the domain from both sides of the front door, and because it grows in exactly the order we need it to.

It starts as a handful of case classes: tables, parties, bookings. Part I queries a day’s schedule with collections. Part II makes illegal bookings unrepresentable and turns validation failures into values instead of exceptions. Part III meets the domain’s hardest problem: two parties grabbing the last table at 8pm, at the same moment, from two web requests. Part IV gives it an HTTP API that documents itself, a Postgres schema that survives restarts, a test suite that would catch every bug this book warns about, and a container to ship it in.

The last-table race is worth flagging now, because it recurs on purpose. We solve it naively and watch it fail, solve it properly with concurrency primitives, solve it again in direct style for comparison, and finally make it durable with database transactions. Same problem, four chapters apart, deliberately: it’s the book’s yardstick for whether each new tool actually improves on the last one.

Every line of Fully Booked, and every exercise solution, lives in the companion repository, checkpointed per chapter so any chapter can be joined cold. Nothing in the book depends on you having typed out the previous chapter.

Two installations and you’re compiling.

A JDK, 21 or newer. Any distribution works; Eclipse Temurin is the safe default if your machine doesn’t already have one. The book’s examples are tested on JDK 21. If you’re on a Java team, whatever you already run is almost certainly fine.

scala-cli. Since Scala 3.5, the official scala command is scala-cli under a shorter name, and it’s all you need for most of this book: it compiles, runs, tests, formats, fetches dependencies, and pins versions from comments in the source file. No build tool, no project scaffolding. (A build tool arrives in chapter 16, when the case study has earned one.)

Verify it:

For an editor, IntelliJ IDEA with the Scala plugin and VS Code with Metals are both first-class; pick whichever matches your Java habits. Nothing in this book depends on an IDE.

The traditional proof of life, in a file called hello.scala:

No class wrapping the method, and no public static void main(String[] args); there wasn’t a build file to feed, either. @main marks an entry point, the compiler generates the JVM plumbing Java makes you write, and Unit is Scala’s void.

One step further, a taste of where Part I is heading. In tables.scala:

That case class line replaces the constructor, getters, equals, hashCode and toString you’d write in Java, and the printout at the end is the free toString proving it. The filter line treats the room as data to query rather than something to loop over, and the _.seats >= 4 inside it is an anonymous function: _ stands for each table in turn, so the line reads "keep the tables whose seats are at least four". Chapter 2 explains what the compiler generated; chapter 3 is entirely about that style of collection work and makes the underscore notation official. For now the point is narrower: two files, two commands, no scaffolding, and you’ve run Scala.

There’s also a REPL when you want to try something without a file:

Some ground rules, so you know what you’re holding/scrolling.

Every code example compiles. The companion repository carries all of them, organised per chapter, and a CI job compiles the lot against the pinned versions: Scala 3.8 (the feature set of the 3.9 LTS line) on JDK 21. Where a chapter uses a library, the version is pinned in the sample sources, so what you read is what ran.

Chapters end with two or three exercises. They aren’t homework padding; each one exists because doing it teaches something the prose can’t. Solutions live in the repository, and looking at them is reading, not cheating.

I assume you’re fluent in Java or another mainstream language and know your way around the JVM. I assume no Scala at all. Chapters build on each other within a part, and the case study threads through the whole book, but every chapter states what it needs and the repository checkpoints let you join anywhere.

One promise back the other way: when something in the ecosystem is contested, pre-1.0, declining, or just a matter of taste, the book says so instead of selling you a stack. You’ll finish with opinions; they should be yours, formed with every tradeoff in plain view.

Flip back to the two functions that opened this chapter. The first one you can already read; by the end of Part I you’ll write it better than most Java-turned-Scala developers do, because you’ll know which Java habits to keep and which to delete. The second one stops being alien in Part III, and, more to the point, you’ll have built a small version of IO yourself before anyone asks you to trust the real one.

Between here and there is chapter 2, which takes the Java you already write and starts deleting ceremony.

Solutions are in the companion repo under ch01/exercises.

Scala has two ways to introduce a name:

No type annotations, because the compiler infers them; covers is an Int and misusing it as anything else won’t compile. You can write the annotation when it helps a reader (val covers: Int = 42), and on public method signatures you always should, but inside function bodies the convention is to let inference work.

The important part is which of the two you reach for. In Java, immutability is a discipline: final on the field, defensive copies at the edges, a reviewer who notices when someone forgets. In Scala, val is the default reflex and var is the deliberate exception. That single habit removes an entire genre of bug, the value that changed under you from three calls away, and it’s why var in a pull request draws the same look that a raw Thread does in Java. Local, contained mutation is fine, and we’ll see honest uses in chapter 3. Shared mutation is the thing the culture pushes against.

Java divides the world into statements, which do things, and expressions, which have values. Scala doesn’t bother: nearly everything has a value, and code gets shorter and safer because of it.

The clearest example is if. In Java you either mutate a variable from both branches or reach for the ternary operator. In Scala, if returns its result:

There is no ternary operator, because this is what if already does. The expression’s type covers both branches, and deposit can be a val because nothing needs to assign it twice.

Blocks are expressions too: the last line of a block is its value.

guests exists only inside the block, and confirmation receives the final expression. Anywhere Java forces you into the pattern of "declare it, then fill it in from several places", Scala lets you compute the value in one place and bind it once. match follows the same rule, and we’ll get to it shortly, because it deserves more than a passing mention.

Our model starts with the shapes we sketched in chapter 1. The chapter opening flattened the party into two fields to match the Java bean; a party is a concept of its own, so it gets a type of its own:

Each of those lines buys the full bean: a constructor, accessor methods, structural equals and hashCode, a readable toString, and two things a hand-written Java class doesn’t give you at any price, a copy method and first-class support in pattern matching. Construction needs no new, and arguments can be named:

If you’re on a recent Java you’re thinking of records, and you should be: records were Java conceding that this ceremony was a mistake. Case classes remain ahead on the working details. Records have no copy, no named or default arguments, and their pattern support was retrofitted onto instanceof and switch years later rather than designed in from the start. The gap has narrowed; it hasn’t closed.

copy is the one to internalise, because it’s how you update immutable data: build a new value that differs where you say and shares everything else.

Nobody who held a reference to marchetti sees anything change, which is the point. Nested updates like this one get wordy as models deepen; live with it for now, it stays manageable at the scale we’ll work at.

Parameters can carry defaults, on case classes and ordinary methods alike:

Defaults belong where a value genuinely is the norm, and they’re one reason you’ll see far fewer overloads in Scala than in Java: most overload sets are one method with defaults trying to get out.

That s"…​" syntax is string interpolation: prefix the literal with s and splice values with $name or arbitrary expressions with ${…​}. We’ve been using it since chapter 1; now it’s official. There’s also f"…​" with printf-style format specifiers for when formatting matters: f"deposit due: £$deposit%.2f" renders the deposit to two decimal places.

A booking has a lifecycle, and its states deserve names:

Java’s enum is close, and everything you’d expect (values, valueOf, ordinal) is here. One scoping difference will bite you once: Java’s switch lets you write bare constant names, but in Scala the cases live inside the enum’s namespace everywhere, so you either qualify them (BookingStatus.Pending) or import them. With that, we can meet match properly:

match is an expression, so describe is a single expression with no return and no fall-through, and there’s no break because cases don’t bleed into each other. But the compiler’s exhaustiveness checking is the real feature. Delete the Cancelled line and compilation warns:

Now add a Seated case to the enum, and every incomplete match in the codebase raises its hand at compile time. This is the workflow that makes evolving a domain model safe: change the type, follow the warnings, done. Java’s switch finally does this too, on sealed interfaces from Java 21; Scala teams have been leaning on it for two decades, and chapter 7 builds a whole modelling style out of it.

An enum can also carry methods of its own, with this being whichever case they’re called on:

BookingStatus.Confirmed.active is true. File the shape away, an enum with methods that match on this: you’ll be asked to build one yourself before Part I is out.

Patterns go deeper than enum cases. They destructure case classes, nest, and take guards:

The first case reads: a Booking whose Party’s size exceeds the maximum, and I don’t care about the name. In a pattern, `_ means "anything"; expressions give the underscore a second, different job, which chapter 3 takes up. Order matters and the first match wins.

Two more shapes finish the everyday kit. Alternatives share an arm, and @ binds the whole value even while the pattern reaches inside it:

Party.MaxSize back in label is a constant we’re about to define, which brings us to statics.

Scala has no static keyword. Two things replace it, and both are simpler than they sound.

First, definitions can live at the top level of a file: describe and label above belong to no class, and neither did anything in chapter 1. Utility methods stop needing a StringUtils class to squat in.

Second, when you want a named singleton, object declares one:

An object sharing a name with a class is its companion, the conventional home for what Java would make static members: constants, factory methods, and later some machinery we’ll care about in chapter 9. Party.MaxSize reads exactly like the static access it replaces; the difference is that an object is a real value, it can extend traits, be passed around, and generally participate in the language instead of standing outside it.

Java interfaces map to Scala traits, and if you know default methods you already know most of it:

Traits take abstract members and concrete members with implementations, and classes mix in several with commas: extends Notifiable, Auditable. Traits can also carry state, which interfaces can’t. That’s genuinely all you need for now; traits have a second life as the foundation of type-driven design, and that story starts in Part II where it can be told properly.

New in recent Scala (3.7+): tuples with named fields, for the cases where a method needs to return two things and a full case class feels like filing paperwork.

(List[Booking], while we’re here: square brackets are Scala’s angle brackets.) The fields are accessed by name, the compiler checks them, and no class was declared anywhere. At runtime a named tuple is an ordinary tuple, the names existing only for the compiler, so the convenience is free. The judgement call between this and a case class: named tuples are for local plumbing, case classes are for concepts. If the shape has behaviour, appears in more than a couple of signatures, or crosses a module boundary, give it a name and make it a case class. `headcount’s return type is plumbing, so a tuple it is.

The model as it stands, which is also ch02/ in the companion repo:

Three case classes and an enum: the restaurant’s entire written-down knowledge so far, in roughly the line count of one Java getter block. The status enum is deliberately underpowered, a flat list of names with no rules about which can follow which; chapter 7 grows it into a proper state machine. And you may have noticed the model has no way to say a booking lacks a phone number, which is chapter 4’s problem to solve.

Take stock of what you didn’t write in this chapter. No constructors, no getters, no equals/hashCode pairs, no toString. No static, no ternary, no break. Every deletion was replaced by something the compiler now does for you, and that’s the pattern to watch as the book goes on: Scala’s wins are rarely new capabilities and usually old costs removed.

Nothing here changed how you think yet. These are your existing designs at a lower price. The change of thinking starts in chapter 3, where the for loop goes the way of the getter.

Solutions are in the companion repo under ch02/exercises.

Three immutable types do most of the work in everyday Scala.

List is the default sequence. Where Java reaches for ArrayList, Scala reaches here first:

A List is a chain: fast to take the front of, fast to add to the front of, and prepending is common enough to have an operator, :::

tables is unchanged by that line; withNewTable is a new list. Every operation in this chapter behaves that way, and the section on structural sharing below explains why that isn’t the performance disaster your Java instincts suspect.

The expensive direction is the one Java hands reach for first: :+ appends, and appending to a chain means walking all of it. Vector is the indexed sequence, with effectively constant-time access and append, the right pick when you index or the data is large. Swapping one for the other rarely changes any other line, so start with List and switch when you have a reason. And the mapping your fingers are asking about: ArrayList becomes List (or Vector when you index), HashMap becomes Map, HashSet becomes Set.

Map associates keys with values, and it’s where our schedule will live:

There’s also Set for membership tests, and ranges, which are collections too:

All of these live in scala.collection.immutable and are imported by default. The mutable variants exist, live in scala.collection.mutable, and get their own honest section later in this chapter.

First, the notation this whole chapter runs on. An anonymous function is written table ⇒ table.seats >= 4: parameter, arrow, body, Java’s → with one more dash. When the parameter is used exactly once, _ can stand in for it, so _.seats >= 4 is the same function. Each underscore is a fresh parameter, which is how _ + _ means (a, b) ⇒ a + b. And to close an ambiguity chapter 2 left open: in a pattern, _ means "anything"; in an expression, it means "the argument". Same character, two jobs, and you’ll stop noticing within the week.

Everything interesting happens with three methods, and you’ve already met two. map transforms every element and gives you the results. filter keeps the elements that pass a test. They chain, and the chain reads as a sentence:

The third is flatMap, for when the transformation itself produces collections and you want one flat result rather than a list of lists:

Each hour became two sitting times, and flatMap flattened the pairs into one list of ten. That’s java.time.LocalTime doing the time-keeping, used directly: Java’s libraries are Scala’s libraries, no wrapping required. If that name rings a bell, it should: chapter 4 makes flatMap the centre of a much bigger idea, and it helps to have used it on plain lists first.

If you’re thinking Java has streams for this, it does, and they were Java admitting this style had won. The difference is defaults. A stream is something you opt into, pipe through and collect back out of (stream(), then .collect(Collectors.toList()) to leave); in Scala the collections themselves have these methods, the results are already immutable collections, and there’s no ceremony at either end. This is the last time the point needs a Java citation: from here on, pipelines are just how code looks.

Fully Booked needs to know what’s happening tonight. A booking, as chapter 2 left it, is a reference and a party; the time belongs to the schedule, not the booking, so we’ll model the evening as requests pairing a sitting time with a booking. Named tuples, from chapter 2, are exactly the right weight:

A flat list of requests is honest input, but the front desk thinks in sittings, the evening’s seating turns: who’s arriving at eight? groupBy reshapes a collection into a Map keyed by whatever you say:

Close: that’s a Map[LocalTime, List[…​]], but the values are the whole request pairs, still carrying the slot we grouped by. groupMap does the grouping and a transformation in one pass:

Two small things arrived with that. groupMap takes its arguments in two bracket groups, the first saying how to key and the second what to keep of each element; several library methods do this, and until chapter 9 explains why, read f(a)(b) as f(a, b) with better type inference. And type Schedule is an alias: it names a shape without creating anything new, so every signature from here on can say Schedule and mean exactly that Map. That’s the schedule: sitting time to bookings. Reading from it has one wrinkle worth learning immediately. Looking up a key that isn’t there can’t return a bare value (there isn’t one), so Map offers getOrElse with a default:

A quiet ten o’clock is an empty list of bookings, and every query downstream handles it without a special case. Now the questions answer themselves:

Two things worth noticing in coversReport. A Map turned into a list becomes a list of pairs, and lambda parameters destructure pairs positionally, so (slot, bookings) ⇒ names both halves without ceremony. And sortBy needed no comparator: LocalTime already knows how to order itself, and the compiler finds that knowledge, a mechanism chapter 9 has a lot more to say about. One more property, easy to miss: slots with no bookings don’t appear in the report at all, because absent keys are absent rather than present-with-zero. Exercise 1 pokes at exactly that. We’ll run the report at the end of the chapter.

sum back in the opening line is one of a family: count, max, min and friends all collapse a collection into a single answer. They’re special cases of one general machine, foldLeft, which walks the collection carrying an accumulator:

(values hands over the map’s values, and flatten collapses the lists into one.) Read it as: start from 0, and for each booking, produce the next total. Any of the collapsing methods could be written this way, and when no ready-made method fits, foldLeft is what you reach for. That’s all we need from it today; folds turn out to be a load-bearing idea, and chapter 9 returns to them with better tools.

Chains of flatMap and map get hard to read past two levels of nesting, and Scala has syntax for exactly this. A for comprehension with multiple generators walks every combination:

Every slot, and within each slot every booking, flattened into one list of lines. This is not a loop, although it reads like one: the compiler translates it into the flatMap and map calls you’d have written by hand, and yield marks what each combination produces. Here is that translation, performed by hand once so you never have to take it on faith:

Same result, same types. Every for in this book compiles down to calls like these, which is why for will keep working, later, on things that are nothing like collections.

Guards filter combinations inline, and to ask the next question we’ll give the room a type of its own, since half this chapter’s questions are about it:

Which tables could take this party? A query, written as one.

One everyday operation needs a moment of care. find returns the first element passing a test:

Notice what came back: not a Table, but a Some(Table(9,6)), and when nothing matched, a value called None rather than a null or an exception. find can fail, and its return type says so. The standard library does this everywhere an operation might have nothing to give you: headOption, maxByOption, Map’s plain `get. For today, pattern match on the result or supply a fallback with getOrElse, both of which you already know how to read. What this type is and how to work with it fluently is chapter 4, in its entirety. Consider this a sighting.

You’ve now met the methods the case study needs. A few more turn up constantly in other people’s code, so here they are, each in one line on data we already have.

collect is filter and map in one move. Its argument is a function defined by patterns, braces and case, and anything that matches no pattern is dropped:

partition splits by a test in one pass, destructuring straight into two names:

zipWithIndex pairs each element with its position, which with mkString turns the evening into a printable run sheet:

exists asks whether any element passes (Java’s anyMatch), and forall asks whether they all do:

One behaviour to know before it bites: on an empty list, forall answers true and exists answers false. An empty room contains no table that fails the seats test, so the claim stands unopposed; logicians call this vacuous truth, and Java’s allMatch behaves the same way. The bite comes in reports: "every booking tonight is confirmed" is a proud sentence to print over zero bookings, so when emptiness deserves a different answer from success, ask nonEmpty first.

Finally, lists destructure in patterns with the same :: that builds them:

You’ll read that shape often in other people’s code; day to day, headOption and the combinators do the same jobs with less ceremony.

All of it is at its best in the REPL, where every experiment comes back with its type attached:

Every operation so far returned a new collection, and your Java instincts have been objecting for pages: surely all this copying is ruinous.

It would be, if it were copying. Immutable collections share structure instead. Prepending to a List allocates one node pointing at the existing chain, and both lists share everything but the new head, safely, because neither can ever change. An updated on a Map rebuilds the handful of nodes on the path to the change, roughly the logarithm of its size, and shares the rest of the tree. Sharing is only sound because mutation is impossible, which is the neat trick of the whole design: immutability is what makes not copying safe.

The costs that do exist are honest ones: List is a chain, so walking to the middle is linear, which is why Vector exists. When a measured hot path wants an array, use an array. Which brings us to mutation.

Immutability is the default, and defaults have exceptions. Scala’s mutable collections are real, supported and sometimes the right call; the discipline is containment.

A mutable map, filled by a for …​ do loop (do instead of yield: no result, only effects), then sealed with .toMap before it leaves. Callers receive an immutable value and can’t tell a mutable builder was ever involved, which is precisely the point: mutation that never escapes a function is an implementation detail. Shared mutation, a structure two parts of a program can both see and both change, is the thing all the defaults are protecting you from. The convention of importing mutable and writing mutable.Map at use sites keeps the choice visible to reviewers.

For the record, the library would have done it anyway:

Three bracket groups this time: keyed by party size, each booking contributing a 1, the ones summed. Worth knowing both: the builder pattern for when logic gets genuinely stateful, the one-liner for when it doesn’t.

We can now write the front desk’s core operation. Can we seat this party at this time, and if so, record it:

canSeat treats every table as interchangeable, one booking per table, which is a simplification we’ll live with; matching parties to specific tables stays the door’s job until chapter 4 gives us the tools. Note also that book returns the schedule unchanged when it can’t seat the party, which quietly swallows the request. Representing "this didn’t work, and here’s why" as data is chapters 4 and 8’s business, and this function will be embarrassed by then.

The evening, assembled, which is also ch03/ in the companion repo:

The restaurant can now answer what its evening looks like, in code that states questions rather than mechanisms. Loops as the default didn’t survive contact with this chapter; neither did the null checks a Java schedule would carry, though you may not have noticed their absence, which is rather the point. What you did see was find handing back Some and None, values from a type we’ve been stepping around all chapter. Time to stop stepping around it.

Solutions are in the companion repo under ch03/exercises.

Fully Booked needs to look up a booking by its reference. Here’s the Java version, as found in the wild:

The comment is doing the type system’s job, and comments don’t get compiled. Callers have to remember to check. Some will.

There’s an obvious objection here: Java has had java.util.Optional since 2014. True, and if your codebase uses it at every boundary, you already believe this chapter’s argument. But Optional arrived twenty years into Java’s life, and it shows. The collections API predates it, so lookups still return null. Java’s own guidance warns against using it for fields and parameters. Strangest of all, a method declared to return Optional<Booking> can still return null: the type that exists to end null can itself be null.

Scala’s Option wins as a commitment more than as a design. It has been in the standard library from the start, so the APIs that can come up empty all return it, and the ecosystem grew up assuming they would. When there is exactly one way to say "nothing", saying it stops being a risk.

An Option[A] either holds an A or holds nothing. Conceptually:

(The + in [+A] marks the type parameter as covariant, which is what lets the single None value serve every kind of Option. Copy it on faith for now; Part II earns it.)

An Option[Booking] is either Some(booking) or None. That’s the entire mechanism. Absence used to be a property of the reference, invisible until you dereferenced it; now it’s a value with a type. The compiler won’t let you treat an Option[Booking] as a Booking for the same reason it won’t let you treat an Int as one: it isn’t one.

Our model grows some honest fields. A booking has a party, and it may also have contact details and a table preference. Not every diner hands over every detail, and now the model says so:

In the Java version of this model, phone is a String that’s sometimes null, and the code that formats it works until the first customer who didn’t leave a number. Here, phone: Option[String] is documentation the compiler reads.

Constructing options is unexciting, which is the point:

And the lookup that opened this chapter no longer needs its comment:

We used find in chapter 3, and its return type is why this method is one line: a search can come up empty, so find returns Option. The standard library already works the way this chapter is arguing you should.

Because an Option is an ordinary value, pattern matching works on it, exactly as it did on the enums in chapter 2:

Handle both cases or, with warnings enabled, the compiler objects. The forgot-to-check-for-null bug is no longer something you can type.

The first instinct is to get the value out of the Option as fast as possible and carry on as before. There’s even a method for it: .get. Resist it. Calling .get on a None throws, so every .get quietly reintroduces the exact gamble Option exists to end.

The idiomatic move is the opposite one: leave the value where it is and transform it in place. map applies a function to the contents if there are any, and does nothing otherwise:

If the booking was found, this is Some(4). If not, the None flows through untouched. Absence stays encoded and travels with the value, so nothing downstream has to re-check.

Chaining is where this starts to pay. The reminder service wants the digits of a booking’s phone number. The booking may not exist, and if it does, the phone may not be on file:

Why flatMap in the middle? _.phone is itself an Option[String], so plain map would produce an Option[Option[String]] and you’d have two layers to unwrap. flatMap transforms and flattens in one step: if any link in the chain is None, the result is None; otherwise the value carries through every step. Remember this shape. We’ll meet it again.

Here’s the same logic in defensive Java:

The Scala version is shorter, but that isn’t the argument. The Java version checks for absence twice in the middle of its logic, and then returns null anyway, handing the same problem to its own caller. The Scala version checks zero times, because the type does the checking, and it returns an Option, so its caller knows exactly what it’s holding.

Chains of flatMap compose fine, but past two or three steps they become arduous to read and reason about. In chapter 3 we used for comprehensions over collections; the same syntax works on Option, because for in Scala is not loop syntax. It’s a readable spelling for exactly these flatMap and map chains, and the compiler translates one into the other.

The confirmation service prefers to text people:

Read each ← as "and this also has to be there". If every step produces a value, the yield runs. If any step is None, the comprehension stops and the whole result is None. It’s the nested null-check pyramid from the Java example, flattened, with the checking moved into the type.

Guards work too. Honouring a table preference means the preferred table has to exist and has to fit the party:

There are three distinct ways for this to produce None, and the body handles none of them explicitly. It describes the successful path; the signature admits everything else.

A preference is a preference, though. If we can’t honour it, any table big enough will do, and orElse expresses the fallback:

Note that orElse returns another Option. On a full night the fallback fails too, and the type won’t let anyone pretend otherwise.

Eventually a value has to leave the box, because something concrete needs producing: a rendered email, an HTTP response. At that point "maybe a string" has to become an actual string, and the everyday tool is getOrElse:

Every getOrElse is a small design decision, because the default you supply is data and you are its author. Pick defaults that are obviously defaults, like "no phone on file". Don’t pick defaults that could pass for real data. The empty string is the classic mistake: absence dressed up as content, and it will sail through checks that null would have failed loudly.

When the present and absent cases both need real work, fold covers them in one expression:

The default comes first and the function second, and yes, everyone looks up the order for the first month. If fold reads cryptic to you, a pattern match does the same job in more lines, and there is nothing wrong with that.

One more family, for interrogating an Option without ever unwrapping it:

exists runs a test on the contents and is false for None; contains compares against a value directly. Option.when(condition)(value) builds an Option from a condition, replacing the if-Some-else-None dance you would otherwise be writing by day three. All three appear constantly in working code.

Once Option is in your vocabulary, API design gains a near-mechanical rule: if absence is a normal outcome, put it in the return type.

The standard library applies this rule everywhere. Map#get returns Option because missing keys are normal. head on an empty list throws, so headOption exists; the same pairing repeats in min/minOption and max/maxOption. The suffix is the library pointing you at the safer signature.

Two refinements to the rule.

First, Option answers "was there one?" and answers nothing else. If the caller deserves to know why there’s nothing, None carries no explanation, and Option is the wrong tool. Errors that come with reasons are chapter 8’s subject, and the type that handles them will look familiar by the time we get there.

Second, be more suspicious of Option in parameter lists than in return types or fields. An Option field on a domain model is honest data; that’s exactly what phone: Option[String] is doing for us. An Option parameter, though, often means one method is doing two jobs: one for callers that have the value and one for callers that don’t. Scala’s default parameters usually express that split better. This is a guideline rather than a law, but when you write an Option parameter, check whether two clearer methods are hiding inside the one you’ve got.

None of this makes the JVM go away. Java libraries still return null, System.getenv still returns null, and your Scala code will call plenty of both. The rule that keeps the model intact: null stops at the border.

The Option constructor is the checkpoint. Option(x) returns None when x is null and Some(x) otherwise:

Wrap a nullable Java API at the point of contact, and absence is encoded from that line onward. Be careful to use Option(…​) and not Some(…​) for this. Some(null) is legal, means "definitely present: nothing", and is never what you want. When a value’s provenance is Java, it’s Option(…​) every time.

For Java’s Optional, the standard library ships converters:

Here are the chapter’s pieces assembled, which is also the state of the case study in the companion repo (ch04/):

Every place the domain can come up empty is now recorded in a signature instead of a comment. Nothing in Fully Booked can trip over an absent value without the compiler having first made someone acknowledge that the value might be absent.

Option is the first example of this book’s central trade: take a discipline that Java enforces through convention and code review, and hand it to the compiler. The cost is a little ceremony at the boundaries. The return is that a whole category of production incident stops being possible to write. It’s also our first meeting with a shape, the chain of steps where any step can come up empty, that Scala keeps reusing: chapter 8 applies it to errors that carry reasons, and Part III applies it to entire programs.

Before either of those, chapter 5 puts a test harness under what we’ve built, because "it compiles" is a necessary standard, not a sufficient one, even here.

Solutions are in the companion repo under ch04/exercises.

Scala has several test frameworks. ScalaTest is the incumbent, with a family of DSL styles that let suites read like prose, and flexible enough that a long-lived codebase usually accumulates several of the styles at once; you’ll meet it in the wild. This book uses munit: it’s minimal, it looks like the JUnit you already know, scala-cli tests itself with it, and it saves its cleverness for failure output, which is where cleverness belongs.

Two things make tests run. The first is a dependency. Chapter 1 mentioned that scala-cli pins versions from comments in the source; the conventional home for those directives is a file called project.scala, which until now would have held one line, and now holds two:

The second is a naming convention: scala-cli treats any file ending in .test.scala as test code, kept out of your production build. In availability.test.scala:

Each test(…​) takes a name and a body, and the names are sentences about behaviour, not method names. canSeatReturnsFalseWhenFull tells a future reader nothing that the code doesn’t; "a full sitting refuses another party" tells them what the restaurant believes.

Run them:

A passing suite is quiet: counts, not celebrations. The tool earns its keep when something breaks, so let’s break something on purpose: assert that eight o’clock holds 16 covers when the schedule says 15.

That’s assertEquals failing: it prints the offending source line, both values, and a diff. On an Int the diff is comically unnecessary; on a nested case class with one wrong field buried three levels deep, it’s the difference between a ten-second fix and ten minutes of squinting, and it’s most of why this book prefers assertEquals(actual, expected) over a bare assert(actual == expected), which can only report false.

The everyday assertion kit is small: assert for booleans, assertEquals for values, intercept[SomeException] for code that should throw. Exceptions are rare guests in our code so far, and Part II is about keeping it that way, but the JVM ecosystem throws, and intercept is how a test pins that down.

Test suites in Java grow @BeforeEach methods the way gardens grow weeds, because shared fixtures get mutated by one test and must be rebuilt for the next. Look at what our suite does instead: schedule, room and bookings are the same immutable values from chapters 3 and 4, declared once, shared by every test in any order. (They’re top-level definitions in the same project, so the suites see them without any import ceremony.) No test can corrupt them, because nothing can corrupt them. The discipline Part I has been selling pays a small dividend here and a much larger one in chapter 12, where the things under test start running at the same time.

Options, meanwhile, make the edge cases first-class test subjects. Chapter 4’s types forced us to admit which lookups can come up empty; the suite now pins down what "empty" means:

No special matchers, no null-handling gymnastics: Some(Table(7, 4)) and None are ordinary values, so ordinary equality does the job. The Okafors not getting a text is now a documented decision rather than an accident of the data.

The test-first loop you may know from Java works the same way here, with one twist worth savouring. Fully Booked needs to issue booking references, so we start with the test:

Run it, and the red isn’t a failing assertion:

In Scala, red is very often a compile error, and that’s the system working: the test states a contract, and the compiler is the first reviewer to point out nobody has honoured it. Now the implementation, using two tools from chapter 4’s kit:

maxOption, because the maximum of an empty list is not a number, and getOrElse to seed the sequence. Run again, both green, loop closed. One honest confession while we’re here: toInt throws on a malformed reference, so this function trusts its input. Making bad references impossible to construct, rather than trusting, is Part II’s project, and this line gets revisited.

Discipline includes knowing when to stop. We don’t test that copy copies or that equals compares; chapter 2 explained who wrote those methods, and the compiler’s homework doesn’t need marking. We don’t test the standard library: groupMap works. Tests go where decisions live, `canSeat’s threshold, `assignTable’s fallback, `nextReference’s seed, because decisions are where we’re allowed to be wrong.

Two names for later, so you know the ground we’re deliberately not covering yet. Property-based testing, where the machine generates hundreds of inputs hunting for the one that breaks your invariant, gets proper treatment in chapter 19, and it will love functions like Party.capped. And testing code that talks to databases and networks has its own chapter’s worth of honest tradeoffs, also chapter 19, once there’s a real service to point it at.

The case study now carries its first suite, ch05/ in the companion repo: availability, table assignment, contact preferences and reference issuing, seven tests pinning down every decision Part I has made, with the exercises adding eight more. Here’s the run for the chapter’s own two suites; the exercise suites join the output as you complete them:

And that closes Part I. Take stock of where you stand: you write Scala that a "better Java" shop would merge without comment, immutable by default, modelled with case classes and enums, queried with collection pipelines, honest about absence, and tested. That’s the first Scala from chapter 1, and it’s real, productive Scala; plenty of professionals never leave it.

We’re leaving it. Part II is where the second Scala starts earning its reputation, and it begins with a question that sounds innocent: if a booking is a value you can pass around, why isn’t a policy? Functions are about to become data.

Solutions are in the companion repo under ch05/exercises.

The arrow you’ve been writing in lambdas since chapter 3 is also a type:

Int ⇒ Int reads "a function from Int to Int`", and it’s a type like any other: `double is a value of that type the way 4 is a value of Int. Calling it looks like calling anything else, double(21). Two-argument functions write the parameters in parentheses: (Int, Int) ⇒ Int.

That’s the entire mechanism, and the reason it matters is what it lets us name. A pricing adjustment takes a quote and returns a quote:

A Quote carries its booking, a running total, and the trail of what’s been applied so far; charge is a case-class method that returns the adjusted copy, chapter 2’s immutable update in its working clothes. And PricingRule is a type alias, exactly like chapter 3’s Schedule, except this one names a shape of behaviour. The owner’s rules are now values:

Two policies, two `val`s. No interface, no implementing classes, no factory. When the rule doesn’t apply, it hands the quote back untouched, which will matter in a moment when rules start chaining.

A function that takes a function is nothing special to write; the parameter just has an arrow in its type. Cancellation refunds depend on how much notice the diner gave, and the policy for converting notice into a refund fraction is, of course, a function:

refundDue never knows which policy it’s applying, and that’s its whole value: the calculation is written once, and the policy varies per restaurant, per season, per whatever the owner dreams up next. You have been using this shape since chapter 3, on the other side: filter, map and sortBy all take functions, and now you’re writing your own.

One Java note, since this is the chapter where the comparison genuinely earns its keep: everything the Strategy pattern achieves, a function parameter achieves without the costume. The interface was only ever there to give one method a name to travel under.

December arrives. The owner wants a seasonal surcharge, but the amount changes yearly, so hard-coding it into a val is one December too clever. Write a function that returns the rule:

seasonalSurcharge is a rule factory: call it with this year’s number and a PricingRule comes back. Look at what the returned function does, though: it uses amount, a parameter that belonged to a call that has already finished. The function closed over it, which is why this arrangement is called a closure. The rule carries its configuration inside itself, permanently, and no field, no constructor and no class was involved in the carrying.

Factories compose with everything else this chapter builds, and they’re the answer to a question you should be asking: "where did the config go?" It went into the function. That’s the point.

Two rules make a pricing policy when one runs after the other, and function values come with the plumbing built in:

andThen glues functions: f.andThen(g) is a new function that applies f, then g to the result. (Its mirror, compose, runs the right side first; this book writes andThen because it reads in execution order.) eveningPolicy is itself a PricingRule, indistinguishable from a hand-written one, which is composition’s quiet superpower: the combined thing is the same kind of thing as its parts.

The owner will not stop at three rules, so the general form takes a whole list:

Read it with chapter 3 eyes: start from identity, the function that returns its input unchanged (the standard library ships it; the square brackets pick which type’s identity you mean), and fold each rule on with andThen, the same andThen as above, written infix the way any alphabetic method may be. The accumulator isn’t a number this time, it’s a function, and foldLeft neither knows nor cares. If you want one image of what "functions as values" buys, it’s this: a fold whose running total is behaviour.

Order matters, incidentally. A percentage-based rule composed before a flat charge prices differently from one composed after it, and exercise 1 makes you feel that properly rather than nod at it here.

An honesty section, because you’ll trip on this within the month if nobody tells you. The `def`s you’ve written since chapter 2 are methods, and a method is not a function value; it’s a member of something, JVM heritage the compiler doesn’t hide. What the compiler does do is convert automatically whenever you use a method where a function is wanted:

filter wants a Party ⇒ Boolean, isLarge is a method, and the compiler builds the function value on the spot. The conversion has a name, eta-expansion, which is worth knowing only so that the word doesn’t frighten you in a code review. Day to day: write def for things with names and doc comments, write val lambdas for behaviour you’re about to hand somewhere, and let the compiler blur the difference.

Values go in collections, and functions are values, so this compiles and quietly replaces a factory class:

A Map from names to behaviour, and chapter 4’s lookup discipline applies unchanged, because there is nothing special about a value that happens to be callable. The "no-shows-bite" entry refunds nothing regardless of notice; _ => BigDecimal(0) ignores its argument, and by now that underscore reads itself.

Configuration-driven behaviour, runtime selection, pluggable policies: the phrases that fill Java architecture decks come down to "keep functions in a data structure and pick one". It’s fine to feel short-changed. It stays this simple.

Assembled, and in the companion repo under ch06/ with its test suite:

The Chen party of six picks up the large-party charge and not the window hold (they didn’t ask for table 9), the note trail says exactly what happened, and the same paid total refunds differently under different policies selected by name. Every piece is a value; the whole engine fits on one screen.

Something changed in this chapter, quietly. In Part I, values were data: bookings, tables, schedules. Now behaviour is a value too, and every tool you already own, Map, foldLeft, Option, works on it unchanged. That’s the type-driven middle ground chapter 1 promised, and it’s also the first step of the staircase’s upper flight.

But notice what the compiler still can’t see. Nothing stops a PricingRule that charges a negative amount, a Party of size zero, or a cancellation policy that refunds more than was paid, because our types so far describe shapes, and shapes admit nonsense. Making the nonsense unrepresentable is chapter 7’s job, and it’s where BookingStatus finally grows up.

Solutions are in the companion repo under ch06/exercises.

A booking has a life: requested, confirmed, seated, and eventually concluded, cancelled, or a no-show. Here’s how that knowledge usually gets recorded, in Scala shops as much as Java ones:

Count the states. Three booleans and two options make thirty-two combinations, and the domain has about six. confirmed = false, seated = true is a diner who sat down at a table nobody gave them. cancelled = true with seated = true is a ghost eating dinner. assignedTable = None with seated = true seats a party on the floor. Every one of those compiles, so every one of them will eventually be constructed by a bug, and the code that reads this record grows if guards like scar tissue, each one re-checking an invariant the last function also re-checked, because no function can trust the shape it was handed.

The flags aren’t the crime. The crime is that the type admits combinations the business forbids, which outsources the business rules to the discipline of every future maintainer.

Chapter 2’s BookingStatus was a flat list of names, and we said it would grow up. Here’s adulthood: one case per real state, each carrying exactly the data that exists in that state.

Enum cases can carry fields, exactly as Contact.Sms(number) did in chapter 4, and the payloads do the real modelling work. A table is held from confirmation, so Pending doesn’t have one and Confirmed can’t lack one. Cancellation notice exists only on cancellations, so the Option[Int] from the flags version disappears: not because we handled None well, but because the question "what’s the notice on this seated booking?" can no longer be asked. The thirty-two states are now six, and all six are true.

This is the single most transferable design move in the book. When you find yourself writing a case class where certain fields are only meaningful when certain booleans are set, you are looking at a sum type folded flat, and unfolding it deletes bugs you haven’t written yet.

States are half a state machine; the other half is which moves are legal. Functions own that:

Each transition pattern-matches on the states it accepts and refuses the rest, so the machine’s rules live in one screen of code instead of scattered guards. You can’t seat an unconfirmed booking because seat won’t have it; the Confirmed(table) pattern even hands over the table for the Seated state, data flowing along the transition. Note cancel accepting two states through one alternation arm, chapter 2’s | earning its keep.

The Option return is doing honest work meanwhile: a refused transition is a normal outcome, so it’s in the signature. Hold that thought for the chapter’s end, because "no" is only half an answer.

And the cancelled state now hands chapter 6 its input on a plate:

The notice hours were captured when the cancellation happened, typed, impossible to lose, and the pricing engine from last chapter consumes them without either chapter knowing the other’s internals. Models and functions composing across chapters is what "the type-driven middle ground" was pointing at.

You met the compiler’s exhaustiveness warning in chapter 2 as a safety net. At model scale it becomes something better: a work list.

Suppose the owner adds a waiting list, so Waitlisted joins the enum. The moment it does, every match over BookingStatus that names its cases raises the chapter 2 warning with the missing case listed: active above, and every piece of reporting or display logic we write from here. The compiler walks you through your own codebase pointing at each place the new business rule needs a decision. Change the type, follow the warnings, done: the same workflow, now maintaining a domain model instead of a toy.

Notice who stays quiet, though: all five transitions, because each ends in case _ ⇒ None. Every wildcard in a match over an ADT is a place the work list goes silent, a decision made in advance for states that don’t exist yet. In transitions that’s defensible, "everything else refuses" being the actual rule, and Waitlisted refusing to seat is probably right. In anything that interprets states, reporting, display, billing, prefer listing the cases, so that growth knocks on the right doors. Where you spend the wildcard is where you’ve pre-signed the decision.

An enum is compact syntax over an older shape you’ll meet constantly in the wild:

sealed means "all direct subtypes live in this file", which is what makes exhaustiveness checkable: the compiler can see the whole family. A case object is a case with no fields, singleton by construction. Everything this chapter does with enums works identically here, and the sealed-trait spelling buys flexibility the compact form lacks when cases need their own companions, or a method implemented differently per case rather than matched in one place.

If you’re arriving from recent Java, this whole chapter has been half-familiar: sealed interfaces (17), records (16) and exhaustive switch (21) are this exact toolkit, delivered in instalments. The difference is ecosystem age. Scala’s libraries, its collections and its idioms have assumed ADT-shaped modelling for two decades, so the technique here is the default, not the new feature you have to argue for. This is the last time Part II will need Java for scale.

Some rules aren’t structural. A party size must be at least one and at most Party.MaxSize, and no arrangement of cases expresses "an Int between 1 and 12". For these, the move is a smart constructor: make the raw constructor private and expose one gatekeeper that admits only valid values.

PartySize(0) no longer compiles outside the companion; PartySize.from(0) compiles and honestly returns None. Every PartySize that exists is valid, so functions receiving one check nothing, the chapter’s theme again by other means.

The rest of chapter 6’s unpaid bill falls to the same move: a charge that can’t go negative or a refund fraction that can’t exceed one is a small type with a gatekeeper, built exactly like PartySize. An opinion on dosage, because this technique invites zealotry: wrap the values where an invalid one costs real money or real sleep, sizes, quantities of money, identifiers with formats, and leave ordinary strings and counts alone. A codebase where every Int wears a costume is as unreadable as one where none does. Fully Booked will adopt PartySize at its input boundary when chapter 8 builds one; retrofitting it through five chapters of existing model tonight would churn everything behind us for no new safety, and recognising that tradeoff is part of the technique.

The state machine, run through an evening, ch07/ in the repo:

The Marchettis hold a confirmed table, the Chens can be confirmed but not seated, and the Novaks' cancellation carries its own notice into the refund calculation. Six states, five transitions, no booleans, and no function in the file re-checks what its input’s type already guarantees.

One dishonesty remains, and it’s deliberate, and it’s next. Every refusal in this chapter is a None. Seat a Pending booking: None. Cancel a Concluded one: None. Ask for a refund on a no-show: None. The caller learns "no" and nothing else, and somewhere a front-of-house screen wants to say why: already cancelled, never confirmed, too late. Chapter 3’s book swallowed failures silently; chapter 5 wrote the smell down; this chapter has upgraded the swallow to a polite shrug. Chapter 8 gives failures their own types, and the shrug gets a voice.

Solutions are in the companion repo under ch07/exercises.

Either[E, A] holds one of two values: a Left(e), which by convention carries the failure, or a Right(a), which carries the success. The conceptual shape:

Where Option had a hole, Either has a second compartment, and everything you learned in chapter 4 transfers. map transforms the Right and leaves a Left untouched. flatMap chains steps that can fail, and the first Left wins: later steps never run, exactly as the first None ended an Option chain. Which means for comprehensions work, because chapter 3 told you they would: for runs on anything with flatMap and map.

Two new tools slipped in there. toIntOption is the standard library’s honest integer parse, Option[Int] instead of the exception toInt throws, and it starts paying down a debt: chapter 5’s nextReference trusted toInt on data it didn’t control, and we said that line would be revisited. The settlement comes shortly. And toRight is the bridge between the two worlds: an Option plus the reason it might be None makes an Either. Absence becomes a named failure at exactly the point you know what the absence means.

One habit to set now: the error type E is real API. Either[String, A] is fine at a REPL and lazy in a codebase, because strings can’t be matched exhaustively, carry no data, and drift with every rewording. Errors deserve what chapter 7 gave states.

Fully Booked takes booking requests from the outside world, and the outside world sends nonsense. Enumerate the nonsense:

An error ADT, built with chapter 7’s toolkit and enjoying chapter 7’s benefits: each failure carries its own evidence (SlotFull knows the slot; PartyOutOfRange knows the size), and message matches exhaustively, so when a new failure mode joins the enum, the compiler points at every renderer that hasn’t decided what to say. The failure channel is a domain model. Treat it with the same respect as the success channel and half of error handling stops being handling at all.

Chapter 7 promised that PartySize and friends would earn their keep at the input boundary. Here is the boundary. A raw request arrives, all strings and hope:

Reference is a smart constructor in the PartySize mould, and it settles chapter 5’s toInt debt for good:

(isDefined reads as it sounds: "is it a Some?".) next still calls toInt, and now it’s allowed to: every Reference in existence passed parse or was built by next, so the format holds by construction. The trust chapter 5 confessed to is now a guarantee, which is what "make illegal states unrepresentable" buys at a boundary: the checking happens once, where the data is dirty, and nowhere else, because past this line the types are clean.

Validation is a for over the failure-carrying steps, and one line inside deserves a beat before you read it: PartySize.from(size) hands back chapter 4’s Option, the map after it is Option’s own, and the toRight on its tail lifts the result into the Either the rest of the for speaks. (parseSlot turns the raw slot string into a vetted LocalTime or an UnknownSlot; it’s defined two sections down, where it belongs, so take its signature on credit for a page.)

Read the shape: steps that can fail, chained, first failure wins, happy path down the left margin. Chapter 4 chained `Option`s this way; chapter 7 built failing steps and left them unchained; this chapter chains them with reasons attached. The costume changes; the shape doesn’t.

First-failure-wins is right for pipelines and wrong for forms. A diner who mistyped the size and the slot deserves both complaints in one round trip, not a correction loop. Accumulation is a different fold over the same checks:

No new machinery: a tuple of independently-run checks, a match on the combinations, and chapter 3’s collect harvesting whichever Left`s exist. It scales inelegantly past three or four fields, and the ecosystem knows it: the Cats library ships `Validated, a polished, general version of exactly this idea, and it will turn up naturally when Part IV’s HTTP layer validates real requests. Today’s point is that you’ve now built the idea it polishes, which is this book’s standing bargain.

The two strategies answer different questions, so keep both spellings: sequential for when later checks depend on earlier ones, tupled accumulation when the checks are independent and the audience is human.

None of this abolishes exceptions, for the same reason chapter 4 didn’t abolish null: the JVM is out there. Java libraries throw; LocalTime.parse throws; JDBC, when we reach it, throws at every opportunity. The rule is the null rule verbatim: exceptions stop at the border.

Try is the border guard, `Option’s cousin for code that throws:

Try(expression) runs the expression and catches anything non-fatal (the JVM’s genuinely broken states, like running out of memory, still propagate, as they should), packaging success or the thrown exception as a value; .toOption keeps the success, and the existing toRight bridge names the failure on the way into our world. One line of border control, and everything downstream of it composes.

Now the opinion this chapter has been building towards. Java’s checked exceptions were the right idea: failure modes belong in signatures, visible to callers, enforced by the compiler. The mechanism sank it. Checked exceptions don’t compose (streams and lambdas simply gave up on them), don’t carry through higher-order code, and punish every caller into catch-and-wrap rituals until throws SQLException becomes throws ServiceException becomes nothing at all. Either is the same promise kept by ordinary values: failure in the signature, but it maps, folds, chains and accumulates with the same tools as every other value in the language. Checked exceptions that compose. That’s the pitch, and unlike the 1996 version, this one has survived contact with higher-order functions.

The boundary, end to end, ch08/ in the repo:

A good request becomes a ValidBooking with a well-formed reference minted for it. A bad one comes back with a reason, and the form-shaped path comes back with every reason at once. Nothing downstream of validate will ever re-check a party size or re-parse a slot: the checking happened once, at the boundary, and the Reference inside is unforgeable by construction.

Twice now, a type with a hole in it has handed us flatMap, and for has made the chains readable: Option in chapter 4, Either here. Chapter 3 promised that for "will keep working, later, on things that are nothing like collections", and it has, twice, without ever explaining what the compiler is actually looking for. There’s a quieter debt from the same chapter: sortBy ordered `LocalTime`s because "the compiler finds that knowledge", and we never said how. Both dodges end in chapter 9, which is about the machinery Scala uses to give capabilities to types, and it’s the chapter where the second Scala’s characteristic move, abstracting over the shape itself, finally gets its proper name.

Solutions are in the companion repo under ch08/exercises.

The restaurant stores bookings by reference, tables by number, and, since chapter 6, policies by name, and every one of those wants the same four operations. Written three times, that’s a bug farm; written once, it’s this:

[K, V] declares two type parameters, and the compiler holds you to them: get on a Store[Reference, Booking] takes a Reference and returns Option[Booking], and handing it a table number won’t compile. The class is written once, ignorant of what it stores, and every use site is fully typed. Functions take type parameters the same way:

The rule of thumb for when to reach for [A]: the moment a function would be copy-pasted with only the types changed, the types are the parameter.

Chapter 4 asked you to copy the ` in `Option[+A]` on faith. Payment time. The ` answers a substitution question: if a Seated is a BookingStatus, is a List[Seated] a List[BookingStatus]?

For immutable containers the answer is yes, and +A is how the container says so: List, Option and friends are covariant, safe because they only ever produce their A`s. A `List[Seated] handed to code wanting List[BookingStatus] can only disappoint by producing a Seated, which is fine, that IS a BookingStatus.

Function parameters run the other way, and a concrete function makes the flip traceable. Take val describe: BookingStatus ⇒ String, a formatter that copes with any status. Code that asks for a Seated ⇒ String only ever plans to feed it Seated values, and describe handles a Seated and more, so handing it over is safe. Scala’s function type declares exactly this: Function1[-A, +B], contravariant in what it consumes, covariant in what it produces. The general-eater substitutes for the picky one; consumption flips the direction. And types that both take and give, like Store’s `V, stay invariant, no marker, no substitution, because either direction can go wrong.

That’s variance for working purposes: + on what comes out, - on what goes in, nothing on what does both. The compiler enforces the annotations against the positions, so lying about it doesn’t compile. When in doubt, leave it invariant and let use sites tell you.

Chapter 8 promised the answer, and it’s disarmingly small. for is desugaring, chapter 3 showed the translation, and the compiler’s only requirement is that the methods it desugars to exist by name. flatMap and map, present on the type, with workable signatures. No interface, no registration, no blessing. Which means chapter 4’s exercise built more than you knew:

Your twenty-line Maybe for-comprehends, because it has flatMap and map, and that was the entire entrance exam. (A guard in the for would add withFilter to the bill, and for …​ do wants foreach; the exam grows with the syntax you use, by name, all the way.)

This shape, a type with a hole and a law-abiding flatMap, is famous: the literature calls it a monad, a word with a reputation it doesn’t deserve. "Law-abiding" is doing quiet work in that sentence, so let it speak once. The laws ask two things of flatMap: chaining must associate, so that stringing three steps together means the same thing however you group them, and the do-nothing wrapper (Just for your Maybe, Some, Right, IO.pure when you meet it) must genuinely do nothing when chained past. That’s the whole rulebook, and you’ve been relying on it unknowingly every time a for block behaved the way it read. Hold the pattern, an operation that associates plus an element that does nothing, because this chapter’s final section is about to charge for it under a different name.

This book will keep calling the shape "the shape"; you’ve used it three times without incident, and in Part III you’ll build the most consequential instance of it yourself. If anyone at a meetup asks, you’ve been monading since chapter 4.

Chapter 3’s report sorted `LocalTime`s and we said "the compiler finds that knowledge" like it was nothing. Here’s the mechanism, and it’s Part II’s last and best trick.

sortBy needs to compare keys, so its signature asks for evidence, which in Scala 3 spelling reads:

Ordering[B] is an ordinary trait, "I know how to compare B`s", and `using marks a parameter the compiler supplies by searching for a given instance of that exact type. The standard library declares givens for Int, String and the rest; LocalTime arrives via a bridge from Java’s Comparable. When none exists, you write one:

One line teaches the whole language to sort tables: sorted, sortBy, max, min, every ordered operation, everywhere, without threading a comparator through call sites the way Java does. That’s the trade given/using makes: you declare knowledge once, the compiler delivers it wherever it’s demanded, and the demand is visible in signatures rather than hidden in globals.

Where do instances live, so the compiler can find them? In the companion object of the type they serve, by convention, and the compiler searches companions automatically. That sentence settles an old account: chapter 2 promised companions held "machinery we’ll care about in chapter 9", and this is it. Ordering[LocalTime] was findable because of where it lives, not luck, and when you write your own typeclass instances, the companion is where they go so that nobody ever has to import them.

Chapter 3 left an IOU too, about methods that take arguments in multiple bracket groups, and it settles here: everything the first group fixes is known before the compiler reads the second, whether that’s typing a lambda’s parameters or, now you know they exist, searching for a given. The grouping isn’t ceremony; it’s the order the compiler learns things in.

Two smaller notes make the mechanism liveable in the wild. In older libraries, the standard library included, you’ll read implicit where this book writes given/using: same machinery, earlier syntax, and you now read both dialects of this, too. And the sugar you’ll meet everywhere: def largest[A: Ordering](items: List[A]) is a context bound, shorthand for a using Ordering[A] parameter list.

A trait some types have instances of, delivered by given, demanded by using: that arrangement is called a typeclass, and Ordering was one all along. (Chapter 2 promised traits a second life as the foundation of type-driven design; you’re looking at it.) They’re at their best describing capabilities with laws, and the workhorse capability of every reporting system is "these things combine":

(The with opens an anonymous instance implementing the trait’s members, the second spelling of given: the alias form assigned an existing value, this form builds one in place.)

A monoid is an associative combiner with a do-nothing element, nothing more; the name comes out of 1940s algebra and, like the other one, is scarier than the idea. What it buys is the general fold chapter 3 promised you’d meet again:

foldLeft was the machine; the monoid supplies its two knobs; combineAll now aggregates anything combinable. And notice the rulebook: an operation that associates plus an element that does nothing, the exact pattern the monad section told you to hold. Monoid demands it of values as `flatMap’s laws demanded it of chaining; the algebra rhymes, and it’s the same rhyme all the way up this language. Watch it earn dinner. The nightly report wants covers and takings per evening, so make the report line itself combinable:

The Takings monoid is built from the Int and BigDecimal monoids, instances composing out of instances, and it lives in the companion where the compiler will find it. Now the whole night is one line:

Add a byHour: Map[LocalTime, Int] field next month and no aggregation code changes anywhere: the Takings monoid absorbs the new field (with a map-merging instance, which exercise 2 has you build), and every combineAll in the codebase picks it up. That is the leverage the second Scala keeps talking about, and notice what it wasn’t: no ideology, no category theory entrance fee, one trait, two givens, and a fold.

Part II is done, so stand on the step and look down. In chapter 1 the second function, the IO-returning one, was unreadable. Look at what’s happened since, without IO being mentioned once: behaviour became values you compose (chapter 6), states and failures became types the compiler polices (chapters 7 and 8), and capabilities became instances the compiler delivers (this chapter). Every move was motivated by a restaurant, not a whiteboard. When someone asks what the FP fuss is actually about, that list is the answer.

One abstraction remains, and it’s the big one. Every function in Fully Booked still just does things; the program runs top to bottom and whatever happens, happens. Part III makes the program itself a value, the way policies became values in chapter 6, and the payoff is the last-table problem from chapter 3, solved properly at last. You’ve built a Maybe. Next you build an IO.

Solutions are in the companion repo under ch09/exercises.

Start with the property we’re about to lose. Everywhere in this book so far, a name and its definition have been interchangeable:

Replace price with its right-hand side, or hoist a repeated expression into a val, and nothing changes. That’s substitution, the property every refactoring you’ve ever done quietly relies on, and it’s why chapters 2 to 9 could reason about code by reading it. Now watch a side effect murder it:

twice and twice2 are the same code by every rule Part I taught, and the diner’s phone disagrees: one text against two. The moment effects run on evaluation, hoisting an expression into a val changes behaviour, which means every refactoring becomes a small gamble, which is precisely the itch you learned to stop having. The compiler sees Unit and shrugs; the type doesn’t even admit anything happened.

Chapter 6 taught the fix without telling you. A function is a value, and a function that hasn’t been called yet has done nothing:

Wrap the effect in a thunk, a zero-argument function, and substitution comes back: send is a description of sending, copyable, passable, storable in a list, and the phone stays silent until somebody calls send(). The problem is that raw thunks are miserable to work with. You can’t map one, chaining two of them means nested calls, and nothing in the type distinguishes "dangerous thunk of side effects" from any other function. What we want is a proper type around the thunk, with the combinators this book has taught you to expect. So build it.

A dozen lines, and read them slowly because they’re the whole trick. An IO[A] is a program that, when run, produces an A. map builds a bigger program: run mine, then transform the result; nothing runs now. flatMap builds a bigger program from a program-producing function: run mine, hand the result to f, run the program f returns. Both return descriptions. The only place anything ever happens is inside unsafeRun, and the name is a convention you should keep: the word unsafe marks the door to the real world.

The two constructors matter too. IO.delay captures an effect without running it (⇒ A is a by-name parameter, the thunk trick with nicer syntax). IO.pure lifts a value you already have; there’s nothing to defer.

And because methods called flatMap and map exist, chapter 9’s entrance exam is passed:

Look at notify before the for: a match on plain data selects a program, text the diner or queue a note for the desk, and the chosen program is just a value awaiting composition. Then the for builds one bigger value: a program that will notify and then write the log line, in that order, when and only when someone runs it. Call confirmationText(chen, Table(9, 6)) a hundred times and nothing happens a hundred times; you’ve manufactured a hundred identical descriptions. Substitution holds again, effects included, because the effects are data now, exactly as policies became data in chapter 6.

A program made of descriptions still has to run eventually, and the discipline is where: once, at the outermost edge, conventionally called the end of the world:

Everything above the last line is pure assembly, testable by inspection, reorderable, refactorable with Part I confidence. The last line is the only place anything is performed; sendSms and logLine remain impure primitives, and every other line in the file merely describes arrangements of them. That separation, effects described everywhere and performed in one place, is the entire architecture of the second Scala, and you’ve now built it from a case class and two methods.

Chapter 8’s rule was "exceptions stop at the border", and IO wraps exactly the code that throws. So give the type its own border control, a new method inside the case class (with scala.util.Try imported at the top of the file):

attempt turns a program that might explode into a program that returns honestly: run it, and you get a Right(a) or a Left(exception), chapter 8’s type carrying chapter 8’s promise into effectful code. A flaky SMS gateway becomes data:

The failure handling is a pattern match on values, composable and testable, and no try/catch interrupts the flow of the program being assembled.

Our IO works, and this section is the honesty that keeps it from being a lie. Three problems are waiting for anyone who ships it.

First, the stack. Every flatMap nests a call inside unsafeRun, so a long enough chain, a loop retrying a flaky gateway all night, say, dies with a StackOverflowError. Real implementations run a loop over a data structure instead of nesting calls (the technique is called trampolining), and it’s the difference between a teaching type and a runtime.

Second, concurrency. Our programs run one instruction after another on whatever thread calls unsafeRun. The last-table problem from chapter 3 is still sitting there, unsolved, waiting for two of these programs to run at once; nothing in a dozen lines addresses scheduling, and chapter 12 needs machinery that does.

Third, safety around resources: files, connections and sockets need closing even when the program between open and close fails, and our attempt is nowhere near enough to guarantee it.

Chapter 11 introduces Cats Effect’s IO, which is this chapter’s type with a decade of engineering where our gaps are: a trampolined, fiber-scheduling, resource-safe runtime behind the same map, flatMap, attempt face you just built. You now know exactly which parts are the idea and which parts are the engineering, which is the only respectable way to adopt a library this central.

Solutions are in the companion repo under ch10/exercises.

Everything from chapter 10 translates by renaming almost nothing: