What Functional Programmers Get Wrong About Systems

35 points by typesanitizer


zesterer

Sigh

This is just another rehashing of the very old 'but dynamic type systems model the real world better because the real world is dynamic' arguments that 'No, dynamic type systems are not inherently more open' does an excellent job of eviscerating.

The problem is in an axiom assumed by the blog post: type systems (which one can extend to things like functional purity) do not exist to model the real world, they exist to label it such that we can usefully start talking about it.

If your types / program flow is not sufficiently capturing the complexity that's present in your domain's data model / execution environment, it means you need to do more work modelling it properly! There's no free lunch, and throwing around any types won't solve your problems!

enpo

One of the points are cross version correctness when deployments are rolling out or when a message in a work queue has been submitted on a different version then what is now processing it (either older or newer due to rollbacks and deployments).

I found TigerBeetle's take on the same problem interesting: They include the old logic when they upgrade so that a new binary can handle the N previous versions as well, and they stamp each operation with the version so that it's always processed by the same version. Details are available over at Jepsen: https://jepsen.io/analyses/tigerbeetle-0.16.11

The relevant section from Jepsen:

TigerBeetle also offers a noteworthy approach to upgrades. Each TigerBeetle binary includes the code not just for that particular version, but several previous versions. For example, the 0.16.21 binary can run 0.16.17, 0.16.18, and so on through 0.16.21. To upgrade, one simply replaces the binary on disk. TigerBeetle loads the new binary, but continues running with the current version. It then coordinates across the cluster to smoothly roll out each successive version, until all nodes are running the latest version available. This approach does not require operators to carefully sequence the upgrade process. Instead, upgrades are performed automatically, and coupled to the replicated state machine. This also allows TigerBeetle to ensure that an operation which commits on version x will never commit on any other version—guarding against state divergence.

rs86

I have a hint the long text was not written by a human.