[1] https://www.amazon.com/Design-Implementation-FreeBSD-Operati...
[1] https://www.amazon.com/Design-Implementation-FreeBSD-Operati...
One could certainly write good articles about why the POSIX API is too limiting. For example: the filesystem API is awful in many ways. I'll try to be a bit more specific (despite having only a few minutes to write this):
* AFAICT, it has very few documented guarantees. It doesn't say sector writes are atomic, which would be very useful [1]. (Or even that they are linear as described in that SQLite page, but the SQLite people assume it anyway, and they're cautious folks, so that's saying a lot.) And even the ones that I think its language guarantees, like fsync guaranteeing all previously written data to that file has reached permanent storage, systems such as Linux [2] and macoS have failed to provide. [3]
* It doesn't provide a good async API. io_uring is my first real hope for this but isn't in POSIX.
* IO operations are typically uninterruptible (with NFS while using a particular mount operation as a rare exception). Among other problems, it means that a process that accesses a bad sector will get stuck until reboot!
* It doesn't have a way to plumb through properties you'd want for a distributed filesystem, such as deadlines and trace ids.
* It provides just numeric error codes, when I'd like to get much richer stuff back. Lots of stuff in distributed filesystem cases. Even in local cases, something like how where in particular path traversal failed. I actually saw once (but can't find in a very quick search attempt) a library that attempted to explain POSIX errors after the fact, by doing a bunch of additional operations after the fact to narrow it down. Besides being inherently racy, it just shouldn't be necessary. We should get good error messages by default.
[1] https://www.sqlite.org/atomiccommit.html
[2] https://wiki.postgresql.org/wiki/Fsync_Errors
[3] https://developer.apple.com/library/archive/documentation/Sy...
Think outside the box people ... "files", what a charming but antiquated concept; "processes" and thus "IPC", how quaint!