Comment by nesarkvechnep
4 hours ago
As always, lists like these don’t include Joe Armstrong's PhD thesis “Making reliable distributed systems in the presence of software errors” - http://erlang.org/download/armstrong_thesis_2003.pdf
4 hours ago
As always, lists like these don’t include Joe Armstrong's PhD thesis “Making reliable distributed systems in the presence of software errors” - http://erlang.org/download/armstrong_thesis_2003.pdf
No disrespect meant to Mr. Armstrong, but it's possible it's never listed because it's basically a textbook. It's 295 pages. The rough average of all papers in OP is like 15 pages.
One can skip the Erlang-specific things/the description of the programming language.
Just the first 2 chapters (~30p) + the Conclusion (~10p) contain a lot of useful food for thought.
His thesis is only slightly longer than typical PhD theses, I think.
I would say 300 is more than slightly longer. Varies by institution and style, but 100k words, 4-5 collated papers, 100-150 pages maximum are quite common.
I would be concerned as an examiner if this came across my desk, more so if I read the colophon where the author comments that they intended to write their own typesetting system, before reading Knuth and wisely concluding that they were unlikely to do anything better than TeX. Top tier yak shaving there.
Yes, but the other things in the OP list aren't theses, they're journal papers.
Are there any other works that should also be included that you know of?
Not OP, but a good resource for distributed consensus specifically is Tim Roughgarden's YouTube playlist "Foundations of Blockchains" [0] (hear me out, despite the title - see below). It's 85 videos over 12 lectures, rigorous, very well explained (but assumes some CS fundamentals). Not original work, but gives the conceptual framework and background so that one can read these classic papers in context.
Per-lecture reading lists are on the course page [1]. He also points at Elaine Shi's Foundations of Distributed Consensus and Blockchains [2] and Andrew Lewis-Pye's Consensus in 50 pages [2] as background, though these are more textbooks, not papers.
Remarkably, the first 7 lectures deal with permissioned systems, recapitulating the classic results of consensus in distributed systems (Dolev Strong, FLP impossibility, CAP) - no blockchain in sight. This takes us to the state of the art at the end of the 1990's (with algorithms that can achieve consensus in the presence of byzantine failures, namely Byzantine Paxos and PBFT, though he discusses a modern variant, permissioned Tendermint from 2014).
Lecture 8 stays permissioned and proves consistency and chain quality for the longest-chain rule. Only at Lecture 9, with proof of work, does anything specifically blockchain appear; then L10 block rewards and selfish mining, L11 transaction fee mechanism design; L12 proof-of-stake sybil resistance with the whole litany of attacks possible there.
Very good series in my view, and shows how little technical merit this whole blockchain circus has - nearly all the great properties people tout (reliability, consistency, audibility, availability) can be achieved with good old permissioned tech more efficiently, with pretty instant and deterministic finality.
Anyway, I found the series worth watching for the classical consensus material alone.
[0] https://www.youtube.com/playlist?list=PLEGCF-WLh2RLOHv_xUGLq...
[1] https://timroughgarden.github.io/fob21/
[2] https://elaineshi.com/docs/blockchain-book.pdf
[3] https://lewis-pye.com/2022/08/15/consensus-in-50-pages/
Does anyone use Elixir/Erlang anymore?
WhatsApp backend in Erlang + used in telecoms
The "WhatsApp used Erlang" story was a decade ago, doubt it is true now.
5 replies →
Yes, but it is boring telecom projects... so most people aren't interested.
Scala is kind of a more modern alternative.
If doing a twitter like platform, elixir with Phoenix channels could handle around >20k users per host. Very few other options work for that use case. =3
reliable? we all wish...
In distributed systems the fist lesson is resilience is more important.
Spend enough time in a computer lab, and you will see things halt and catch fire on occasion. Especially if it has a bunch of GPUs pinning the utilization 24/7, or a cheap power supply in the cluster. =3