Lens is one of my favorite libraries, but I can understand why optics, in general, is a divisive topic. Like many things in Haskell, you won't appreciate optics without suffering through a steep learning curve.
Optics don't just save you a few keystrokes. Instead, they make tedious code that you would never write trivial. And more importantly, they're composable. So it's impossible to appreciate their effectiveness without using them on a real-world app. For example, I've worked in an app with three layers, each with its record types, and without the lens library, the pain of converting between records would have been insufferable. Instead, most developers would couple the three layers together to avoid the problem, which makes the codebase brittle.
DHH’s preferred architecture is a rails monolith with a single database behind it that you keep scaling vertically. I believe both Hey and Basecamp are still using that architecture.
nix-darwin currently does not support that directly, but there is an open PR to fix that. For my dotfiles, I added the module from the PR with some slight modifications. You can find the code below.
Unfortunately, it's extremely rare to find software that exhibits "miryokuteki hinshitsu." The author's examples are not quite right. For example, linear is missing too many core features to be useful for many use cases.
The article premise is completely wrong. Zestimates were never meant to be accurate. In fact, they were deliberately inflated to drive traffic to Zillow.