mrkeen

7 ms·

121.
by mrkeen 3mo ago
The market does reward proficiency. We live in the punished timeline. No contradiction. Most software is buggy and most businesses fail.
122.
by mrkeen 3mo ago
Terrific writing. Just terrific. Copied verbatim: The Lindy effect in software The longer a tech has been around, the more robust it is seen as compared to more recent ones, we often talk about a technology’s maturity The C language S
123.
by mrkeen 3mo ago
Work is outside. Workers are demanding to stay inside (with their AC) instead of going outside.
124.
by mrkeen 3mo ago
The problem is you can't choose which side the gun nuts end up on.
125.
by mrkeen 3mo ago
And yet people were happy to call Snowden a traitor for breaking the news of it.
126.
by mrkeen 3mo ago
in this day and age, are there more useful concepts that we could be giving more attention than CAP, ACID, and friends? Are they useful enough to satisfy the dfsdt principle? I think not. CAP is useful to the extent that: - people
127.
by mrkeen 3mo ago
We're currently running a long-term offshore experiment to see if 2A has any measurable impact on dragnet surveillance and the NSA.
128.
by mrkeen 3mo ago
They're still right here in sibling comments
129.
by mrkeen 3mo ago
Are you arguing that most teams that recognise a need for a distributed system chicken-out and use a single node instead, and if so, is that a good thing?
130.
by mrkeen 3mo ago
Agreed. When they describe the advantages over Raft, I can't help but read 'this is Paxos'.
131.
by mrkeen 3mo ago
I expected to see mention of the Church-Rosser theorem, which may have just turned 90 years old. Pretty good vintage for a comp sci theorem. Anyway the way I learned it is: * for a given lambda expression, all evaluation orders which reduc
132.
by mrkeen 3mo ago
I mean if I was only going to use 'one thing', it would be tech that doesn't have downtime when you replace its parts. Something like Kafka or Cassandra. Then since postgres is useful, I would likely end up adding it into t
133.
by mrkeen 3mo ago
The reason for separate systems is that some of them go down. And by "go down", that includes you wanting to deploy a new version. Or restore from backup as the article suggested.
134.
by mrkeen 3mo ago
You should try more languages
135.
by mrkeen 3mo ago
This is not a bad question! If you flip it and instead ask "how do I write something that can't fail?" you might find some interesting ground. The best things I know about are static type-checking, pure functions and totality
136.
by mrkeen 3mo ago
I don't disagree with anything in particular here, but other developers might fall into a trap with: we are not fully enumerating and reasoning about failure cases. This might put (or keep) a developer in the mindset that they c
137.
by mrkeen 3mo ago
I call it the "doing two things" problem. Your write imperative code, which issues two commands, both of which can fail independently. There are plenty of ways to pretend to 'deal with it'. Firstly it will just pass all
138.
by mrkeen 3mo ago
The internet of 2026. Betteridge's law wrapping a paywall wrapping an AI piece masquerading as domain-specific analysis.
139.
by mrkeen 4mo ago
How much does it cost to rent a db that can do CAP?
140.
by mrkeen 4mo ago
I hadn't heard of throwing money at it before. Maybe "Two Generals" doesn't work, but "Two Rich Generals" does.
141.
by mrkeen 4mo ago
I somewhat agree with 'just use the db' over 'use the db as the state and the outbox'. And message "queues" are probably a waste of time too. Where you get a real benefit is in using a proper append-only ledger
142.
by mrkeen 4mo ago
I have the starting state: DB={} Q={} I would like to either remain in the starting state, or enter a new state: DB={Bob paid $15} Q={Bob paid $15} But this is Two Generals, which is impossible. If you invoke 2PC, you want
143.
by mrkeen 4mo ago
Too much work. Don't try to act as the sender yourself. The outbox pattern leaves that as an exercise for the reader. How many receivers do you have? Do they come and go while you're trying to send messages? Do they need to f
144.
by mrkeen 4mo ago
Yes, same-ordering gives you EC, not the other round.
145.
by mrkeen 4mo ago
But that's what the outbox pattern is. You take the problem of transacting between more than one system, and by "just using the db", you declare the problem solved, leaving the communication with other systems as an exercise
146.
by mrkeen 4mo ago
> The two general's problem is a great piece of reading on this topic It is! And the solution is to add an extra general on the left side. Let's call him Outus Boxus. The two generals on the left side can communicate in perfe
147.
by mrkeen 4mo ago
> then would this generalize to maintaining distributed application state in general? Yes, in the sense of 'too good to be true'
148.
by mrkeen 4mo ago
Step 1: identify that you and at least one other node are separated by distance, and some lossy communication channel, and therefore form a distributed system. Step 2: propose a source of truth that everyone can listen to. Hearing the same
149.
by mrkeen 4mo ago
"Send multiple times from D to Q and deduplicate with a UUID" (idempotency) is well short of "insert into both D and Q or neither" (atomicity)
150.
by mrkeen 4mo ago
Your intuition sounds right to me. This sounds a lot like reinventing a message queue. Someone trying this in the future might learn painful lessons about ordering, commits, partitioning, dead-letter-queues, replayability, don't-call-

More ›