Wow, it surprises me that there aren't more comments on this zine, which I find a delightful way to present interesting CS topics, detailed explanation and pages full of explanatory drawings that speak. The Zines page [0] mentions the definition of a zine:
> "a small-circulation print or online publication that is produced through noncommercial means and is meant to appeal to a niche audience"
So then, is "causally ordered message delivery", "introduction to choreographic programming", and "Fighting Faults in Distributed Systems" too niche for HN? Hand-crafted with human sweat and tears, no AI. Is that the reason then perhaps for the silent comment thread, i.e. TL;DP, "too long, doesn't prompt"?
I've read through ItCP. The illustrations were wonderful, but I was rather annoyed by the typeface.
... And somewhat disappointed by the conclusions. A Java compiler (sans an overview of limitations/capabilities, but I understand the limitations of the format), and a... Haskell library, which, unfortunately, is incredibly irrelevant to me.
How is this subject approached in practice? I'm fairly familiar with authentication (generally handed off to a bespoke service + library that abstracts away most of this for the end programmer), but my generalist experience with other coordination problems between distributed systems is that programmers tend to not be particularly rigorous about them - and try their best to break down cross-service relationships to very, very simple-to-implement-in-a-bespoke-fashion cases.
On this topic, is anyone else bothered by the way most home automation software uses MQTT? They splay messages out into multiple semantically-significant topics, which is an understandably attractive idea for writing simple scripts that change when a variable changes and whatnot. But the MQTT spec does not guarantee ordering across topics! So this has a correctness problem with only two devices communicating, never mind three.
Wow, it surprises me that there aren't more comments on this zine, which I find a delightful way to present interesting CS topics, detailed explanation and pages full of explanatory drawings that speak. The Zines page [0] mentions the definition of a zine:
> "a small-circulation print or online publication that is produced through noncommercial means and is meant to appeal to a niche audience"
So then, is "causally ordered message delivery", "introduction to choreographic programming", and "Fighting Faults in Distributed Systems" too niche for HN? Hand-crafted with human sweat and tears, no AI. Is that the reason then perhaps for the silent comment thread, i.e. TL;DP, "too long, doesn't prompt"?
[0] https://decomposition.al/zines/
I've read through ItCP. The illustrations were wonderful, but I was rather annoyed by the typeface.
... And somewhat disappointed by the conclusions. A Java compiler (sans an overview of limitations/capabilities, but I understand the limitations of the format), and a... Haskell library, which, unfortunately, is incredibly irrelevant to me.
How is this subject approached in practice? I'm fairly familiar with authentication (generally handed off to a bespoke service + library that abstracts away most of this for the end programmer), but my generalist experience with other coordination problems between distributed systems is that programmers tend to not be particularly rigorous about them - and try their best to break down cross-service relationships to very, very simple-to-implement-in-a-bespoke-fashion cases.
On this topic, is anyone else bothered by the way most home automation software uses MQTT? They splay messages out into multiple semantically-significant topics, which is an understandably attractive idea for writing simple scripts that change when a variable changes and whatnot. But the MQTT spec does not guarantee ordering across topics! So this has a correctness problem with only two devices communicating, never mind three.
Programming zines by Julia Evans: https://wizardzines.com
> a collaboration between [student] and me
"...and I"!!!
If you're going to make an effort to write, please don't grind me eyes