I believe that.

FUSE makes me think that the Plan 9 people were on to something. Filesystems actually can be a really nice abstraction; sort of surreal that I could make an application so accessible that I could seriously have it directly linked with Vim or something.

I feel like building a FUSE driver would be a pretty interesting way to provide a "library" for a service I write. I have no idea how I'd pitch this to a boss to pay me to do it, but pretending that I could, I could see it being pretty interesting to do a message broker or something that worked entirely by "writing a file to a folder". That way you could easily use that broker from basically anything that has file IO, even something like bash.

I always have a dozen projects going on concurrently, so maybe I should add that one to the queue.

See https://github.com/matthiasgoergens/git-snap-fs for my example of read-only access to git via fuse.

I built the original version in Python for a job years ago. But the version above is almost entirely vibe-coded in Rust in a lazy afternoon for fun.

However, I disagree that the filesystem is the right abstraction in general. It works for git, because git is essentially structured like a filesystem already.

More generally, filesystems are roughly equivalent to hierarchical databases, or at most graph databases. And while you can make that work, many collections of data are actually better organised and accessed by other means. See https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf for an particularly interesting and useful model that has found widespread application and success.

Yeah I'm not saying that they're necessarily great in general, just that there are certain applications that map pretty well, and for those it's a pretty cool abstraction because it allows virtually anything to interface with it.

Also, looks like my message queue idea has already been done: https://github.com/pehrs/kafkafs

No new ideas under the sun I suppose.