4 ms·

The problem with files is that they usually don't provide what users need or expect in 2024. Having multiple users editing one file at the same time is hard, e

The problem with files is that they usually don't provide what users need or expect in 2024. Having multiple users editing one file at the same time is hard, especially if they're non-technical and they don't understand git diffs. To make that work, you need CRDTs (or operational transforms), and those can't really be represented nicely in plain text formats. Even something like a music library, where you have n devices authorized to make changes, each device keeps an offline copy, and all changes get "synced up" when devices get online, is just far, far easier to implement with a servr guarding over a database than with a raw file on some cloud drive.

miningape 2y ago
I do agree for general users, but the post seems targeted at a more technical audience. I don't expect HR or finance to care about file types and storage beyond being something they know how to work with. I do expect developers to care though, and developers also (generally) prefer "self-managed" solutions like git over CRDT for editing files. I really disagree with this idea in software design that even when you are making a tool for technical people it must be implemented in a way that non-technical people expect. Like how postman is trying to be a google docs for http requests. Programming languages are our favourite technical tools and we don't expect features that are nice for non-techies, we expect features that confuse non-techies but make our lives easier!
munhitsu 2y ago
CRDT at the very low level is an append only operations log with snapshots. This can be easily stored in a file. The trick is to solve merging with another version you just got from a friend. But then operations are idempotent and appending two operation logs with idempotent operations is simple. Yes, ideally OS would provide a container that it natively merges, but meanwhile nothing prevents apps from storing their data in say sqlite based append only logs and when needing to solve conflict/import/merge just append new operations.

miningape 2y ago

I do agree for general users, but the post seems targeted at a more technical audience. I don't expect HR or finance to care about file types and storage beyond being something they know how to work with. I do expect developers to care though, and developers also (generally) prefer "self-managed" solutions like git over CRDT for editing files. I really disagree with this idea in software design that even when you are making a tool for technical people it must be implemented in a way that non-technical people expect. Like how postman is trying to be a google docs for http requests. Programming languages are our favourite technical tools and we don't expect features that are nice for non-techies, we expect features that confuse non-techies but make our lives easier!

munhitsu 2y ago

CRDT at the very low level is an append only operations log with snapshots. This can be easily stored in a file. The trick is to solve merging with another version you just got from a friend. But then operations are idempotent and appending two operation logs with idempotent operations is simple. Yes, ideally OS would provide a container that it natively merges, but meanwhile nothing prevents apps from storing their data in say sqlite based append only logs and when needing to solve conflict/import/merge just append new operations.