I found the article interesting, but I don't think I understand what is meant by 'Write Last, Read first' rule - even after reading it a few times. It seems to be too ambiguous a statement to be helpful.
Under the section 'Order of Operations':
> "Since the system of reference doesn’t determine existence, we can safely write to it first without committing anything. [...]"
Then the next paragraph
> "This principle—Write Last, Read First—ensures that we maintain application level consistency."
What I think it means is, 'writing-last to the system-of-record' and 'a read-first from the system of record' yields authoritative results, but I don't get that just from the title. Is my understanding correct?
Yes, write last to the system of record, read first from the system of record. Or in other words, commit to the system of record, and then read from the system of record to see what's committed.
(This is similar also to how chain replication preserves consistency.)
No, in two-phase commit all target systems perform two phases (staging the commit, which may fail, and then actually committing it in a failsafe way), which isn’t the case here.
You’re thinking too concretely. What do you think you’re doing before you write “to the source of truth”? You’re staging the commit. And then you commit.
2pc isn’t literally about transactions like you are probably thinking of in a database, its an abstract “atomic change” or “unit of work” that may or may not involve a database or a database transaction. You can do 2pc with just normal files, or APIs, or whatever.
I disagree. The definition of a two-phase commit protocol is that you have a number of participants in a transaction, and the first phase consists of asking each participant if they can commit, and if or when all participants affirm positively, then the second phase consists of telling all participants to perform the commit. Let’s not dilute well-established terms.
The procedure in the article is not a two-phase commit, because changes are committed to the system of reference regardless of whether the subsequent commit to the system of record succeeds or not.
In addition, half of the rule in the article is about the ordering of reads, which two-phase commit isn’t concerned about at all.
It’s just moving this into the application level, but it’s still 2pc.
Intent: Begin the durable execution (i.e. resonate.run)
Prepare: Write to the system of reference -- safe to fail here.
Commit: Write to the system of record -- the commit boundary.
Ack/Recovery: checkpointing + idempotent replays.
Abort/Compensation: panic or operator intervention.
Ordering operations has always been a thing you should do. And they’re treating this as a distributed system to simulate an ACID transaction. For example, if you ever do locks of multiple things, the order you take the locks has to be the same across the entire system so that you never deadlock. If your database is taking locks, then order matters there too. They rediscovered what us in the distributed systems world have always known and fairly well-documented: ordering is how you simulate time and prevent paradoxes.
In vscode you can click on various assets, like images or audio files, and then view them right inside vscode. If you work with datasets, the ability to inspect them is crucial.
Yes ofc I can use Finder instead but in vscode I just cmd+p.
While I understand your point, and think you are correct - if the 'Trash' button is not behind a confirmation box, and it's not undoable, then that is a pretty terrible design choice.
I've just grabbed Zed, and both Trash and Delete are behind confirmation boxes. Trash sends to my Trash (recycle bin on windows), and delete properly deletes. There's no built in undo for trash, but I can restore from the trash/recycle bin normally.
yeah I just tried the windows build and they are indeed behind a confirmation box (for both trash and delete). That's not the impression I got this morning from reading OP's comment
OP here. I have muscle memory from many years of using VSCode before Zed.
"Delete" is the last option in the right click menu for both and when you select it both show a very similar dialogue box asking you to confirm.
VSCode's 'Delete' by default moves the file to the trash and can be undone with Ctrl + Z. Zed's 'Delete' skips the trash and can't be undone with Ctrl + Z.
I should have mentioned the confirmation box but after years of use I've begun clicking through that box so quick I didn't realize the behavior was different in Zed.
yeah, the confirmation box makes the issue slightly less egregious, but having trash and delete next to each other in the context menu is imo still an issue.
I'm not necessarily disagreeing with you (because apparently this is missing), but a descriptive constant/variable name would be even less clutter than even a 1-line comment
A variable name that explains both what this is, and why that specific value was chosen would be a very long and cumbersom name. And would beed to be changed if the value was ever changed (to explain the new value).
>> No one would implement a bunch of utility functions that we already have in a different module.
to be fair on this one, and while I don't flat out disagree, lots of people reinvent utility functions simply because they don't know they exist elsewhere, especially on huge code bases. This seems to get mostly rectified within the PRs, when a senior dev comments on it - the problem then is, you've only increased the number of people who now know by 1.
I was contemplating writing something similar, but am often hesitant to post negative comments, but the pricing (without even considering the user and seat restrictions) of this is just crazy considering it's ultimately a GUI wrapper of the CLI tool.
> as the problem seems to be general conduct in social media
is that the problem? I'd have thought the problem is more about the ill effects of social media on children, not the children's behavior on said social media.
Hen or egg? To make it worse, for some it's simple in their nature to show some degree of anti-social behaviour. We all have to learn how to interact with others in a social manner, be it on the playground, school or internet.
Under the section 'Order of Operations':
> "Since the system of reference doesn’t determine existence, we can safely write to it first without committing anything. [...]"
Then the next paragraph
> "This principle—Write Last, Read First—ensures that we maintain application level consistency."
What I think it means is, 'writing-last to the system-of-record' and 'a read-first from the system of record' yields authoritative results, but I don't get that just from the title. Is my understanding correct?