This proposal is crazy town.
If you think about it, if your code is small and clean, you wouldn’t feel the need for shared libraries.
Not so. The key feature of DLLs is to enable software components to evolve independently. When Apple changes the way a button looks in UIKit, all apps get the updated behavior, because UIKit is dynamically linked. This has nothing to do with the app size or its hygeine.
Replacing dylib calls with filesystems and fread/fwrite is absurd. IPC is much harder than library calls. There's the obvious expense of turning every library call into multiple system calls. It's also less flexible. When the interface is a function call, the function can switch implementations from eager to lazy, add or remove caches, etc. But when your interface is fread() you must provide your data up front. Switching a field to computed on-demand is a breaking change.
But the versioning issues are the worst. Reading from Plan9 /dev/mouse returns 49 bytes. I can't add a new field without breaking apps. The equivalent of adding a method in an OO language is now a breaking file format change in this scheme. The post attempts to addresses this:
With filesystems, it’s trivial to add functionality without breaking applications depending on older versions of your FS. That’s because all the compiler sees is a bunch of fopen/fread/fwrites and is not going to complain if the version of the filesystem changes because it doesn’t know.
The app can't break because the compiler can't detect the breakage. Huh?
Alternatively, if you’re thinking of modifying the behavior of your filesystem; consider providing a version file in the root of your FS right from the beginning. Applications would then write the version number they expect to be working with in that file as a way of initializing the filesystem
This sounds very bad:
1. Every API needs to be able to ingest and emit all past versions of themselves, in perpetuity. This is obviously a huge maintenance burden.
2. This does nothing about the reverse problem: how does an app run on multiple versions of the OS? Instead of, say, using reflection to test if a method is present, apps must be prepared to parse the product of every API they use against every OS version they want to support.
3. Applications do not have a single "version number they expect." Apps are built out of multiple components written at different times which consume different versions of the same API. There's no affordance for that.
So we're forced to use some structured data format with named fields, rather than raw bytes. How did this come out of a desire for a "lean, efficient and small" solution?