Protocols

Just like the essence of programming can be reduced to a “mostly-functional” tiny, orthogonal to but complementing each other set of just right features (pioneered by Standard ML and Erlang), protocols can be reduced to some sort of essence too.

Fundamentally, we have sequences of bytes and in-wire encoding.

Since the 60s, reading and writing one byte at a time solves all the problems, but it is inefficient. So, the solution is to have “frames” or “packets” instead of a single byte.

Both frames and packets have a fixed size, a packed structure header and a variable-length body.

A clever bit-patterns could tell you what kind of a “multi-byte payload” will follow, and this is exactly what UTF-8 (variable-length encoding) is. This is the state-of-the-art.

In general, you have a “tagged data”, where a tag (a unique bit pattern) completely defines the payload - length, encoding, etc. All the major languages, since early LISPs, are using type-tagged values internally.

Using the same set of ideas for an in-wire encoding of structured data is almost obvious and “natural” choice.

Libraries like “message-pack” have done a great job of optimizing bit patterns (using frequencies).

Erlang, being a well-researched, principle-guided and even “conservative” (in a rare positive sense) language, (with the runtime and the standard set of libraries) relies on tags and fixed-header messages (and packets) thoroughly, and it is not a coincidence that pattern-matching fits naturally.

So, asynchronous messages, which are transmitted over a packet- or frame-based network is the essence. Just stick to it and your code will be small and correct, as has been demonstrated (proven by example) by lots of successful Erlang-based project in telecoms and other industries.

I am not an expert, but I think the design choices of the hardware guys are exactly the same, because the asynchronous message-passing (through cell membranes), using particular molecular structures (and just ions) is an evolved “stable universal pattern”.

Again, Erlang is unique in being well-researched, principle-guided (no arbitrary choices on a whim) and done almost everything “just right”. It is the esoteric syntax that kept it being a niche language (which is, actually a good thing).

But you cannot see the craftsmanship and the beauty of Erlang without knowing the principles first.

The way they have generalized (as a generic code) Servers and even FSMs is so brilliant (and has been possible in the first place) exactly because the underlying language and the runtime has been done just right.