This book contains a lot of great information for Scala programmers, but it's kind of buried in a frustrating reading experience.

A lot of what you'll learn in this book is that many of the ways you use Scala normally are slow, I particularly enjoyed learning how Option, something I take completely for granted but has the potential to hurt performance in critical areas. It's not just a complaint either, the author basically offers an alternative Option implementation that doesn't suffer from this (and also, isn't as expressive, and is basically Java). There are also some great sections about Free Monads and an absolutely fantastic coverage of the differences between Scala collection types and performance. It's a lot deeper than you might think, it's not just "oh this one is O(n) and this one is O(logn)", it's extremely detailed and informative.

The main issues I have with the book are the writing style and the example used for illustration. The writing style is fluffy and feels both padded and out of place. The author basically takes the reader through almost a choose-your-own-adventure story where "you" have started a new job, and you're talking to people to understand their performance issues, and helping them out. They all have names like "Dave from so-and-so department" and it just feels totally unnecessary. He gets in some cracks about "you" avoiding scrum masters to get real work done and how happy you're making this or that group and increasing the company's bottom line. One one point, "You double-check with Gary to confirm that MVT strategies are thread-safe. He responds with a thumbs up emoji, which gives us the green light to parallelize execution of trading strategies." It just feels so out of place, it kind of reads like the author wrote a dry, matter-of-fact book and then someone told him to make it more of a story to keep readers engaged, and then he shoehorned all of this stuff in like it's The Phoenix Project. It's kind of grating.

The other gripe I've got is that there's a single domain example used as a throughline through the entire book: a high-volume stock trading application. I recognize that this is a fitting example because these kinds of applications really REALLY care about throughput, latency, and performance concerns - I have a buddy who used to work at one of these places and they universally insist on using C++ with a lot of assembly callouts to get nanosecond improvements. However, if you basically know fuck-all about the stock market, a lot of the terminology and domain specifics might go over your head, and there's little to no attempt to explain any of it as the author assumes a base level of familiarity with these concepts. This is probably a personal failing on my part because I hate the stock market and I don't mess around with it much, but I found myself occasionally struggling to understand exactly how the domain worked, and since it's critical through the ENTIRE book, this affects the whole reading.

This book is definitely worth skimming, but I'm not sure if it's worth a full sit-down read. I think the sections can largely be read independently, they rarely build on each other so it's worth going through and picking up the areas where you're particularly interested in performance. If you do Scala full-time, it's definitely worth flipping through if only to find out what kinds of things to look out for, so that you can circle back to the book later on if you encounter particular performance issues.