Miniblog

When Rain mentioned recently they had a draft monad tutorial that explains them without mathematical jargon, with practical examples, and as a design pattern, I knew it was going to be good. Of course, it is even better than I hoped.

“Demystifying monads in Rust through property-based testing” is an undersell of a title. If you’ve floated around the world of functional programming long, you’ve probably seen one of the many attempts at explaining monads. Many are from the perspective of a formalism—the monad laws—and written with Haskell—the language that made them a central feature with syntactic sugar and a direct to how IO is done.

Rain instead introduces monads with a practical example of how their flexibility actually makes some work harder, motivated with a concrete example of how “shrinking,” a core operation for doing practical property-based testing, becomes much more difficult when monadic operations are used to generate test inputs. Instead of Haskell, the tutorial uses Rust.

Thanks Rain for the best monad tutorial I’ve ever read!

I’d like to stake a radical position: the Git Version Control System (VCS) will be declining in popularity in 5 years, and Jujutsu (jj) will be gaining popularity in its place.

Of course, Git is the most popular VCS today by a wide margin, with a large ecosystem of companies and tools built around it.

However, I believe Jujutsu will displace it for three reasons:

1. Jujutsu can be adopted locally on Git projects. You can use Jujutsu as an individual contributor on a project that doesn’t use it. It can be adopted incrementally by teams, and does not require a cutover from one VCS to another, which history has shown to be a slow, expensive, and difficult process.
2. Jujutsu’s design makes dev work easier. Jujutsu has learned from Git, Mercurial, and others, and features a model which is, to paraphrase Steve Klabnik, “simpler and more powerful” than Git’s. By removing edge cases and sources of complexity from Git, Jujutsu’s features compose better together, allow more powerful control over your commit history, and make day-to-day operations on collaborative software projects easier.
3. Jujutsu’s interface is easier to use. Not only is Jujutsu’s data model simpler and more powerful, but its Command Line Interface (CLI) is also much easier to understand than Git’s. This is both because the data model is simpler (so fewer flags to handle edge cases are needed), and because the CLI itself is better designed. Flags are more consistent across commands, terminology is more consistent, undoing operations is predictable and much easier.

Of course, I may be wrong. Jujutsu is production ready for many users, but it has not reached version 1.0 yet. Displacing an entrenched technology is also difficult, and there are many ways it could go wrong.

Yet using Jujutsu, I have the same feeling I had writing Rust in 2014 as a C++ programmer: this is better. This is a system that makes many of the failure cases I’ve encountered impossible, and makes the few remaining tough cases much easier to resolve. Day-to-day, I find myself less worried about managing my changes to reduce the likelihood of possible merge conflicts; in fact I am rarely worried about conflicts at all. It’s easier to use, easier to teach, and lets me move faster and with more confidence.

One of Rust’s historic taglines was “Fearless Concurrency.” Maybe Jujutsu’s should be “Fearless Collaboration.”

I really like Jack Wrenn’s new article “The Three Basic Rules of Safety Hygiene,” which covers how to handle unsafe code when you have to write it, through a hygiene checklist for expressing and validating compliance with safety conditions in the code.

Rust’s goal is not to eliminate unsafe code, but to contain it in isolated modules you can audit and which provide safe interaces to external users. Sometimes unsafety is necessary, and having a process for how to handle that unsafety is a key development.

Research on how to reduce things like industrial accidents, medical incidents, and airplane crashes all consistently find that checklists and procedures work. Humans are fallible, and being accountable to a checklist or a process defends against our propensity to make mistakes.