[josephg]

> ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant.

The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS.

But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're certainly still paying a cost. Plenty of benchmarks have been made over the years showing how better APIs can yield 20+% more filesystem & TCP socket performance on linux by bypassing write() and friends. If you spend $10k on a database or application server, think about it as $2k of that hardware wasted simply due to bad kernel APIs. And I'm sure there's plenty of features postgres and sqlite don't have because their devs instead needed to spend their days in a desperate struggling to make their software work correctly, at all.

Aside from performance, in my opinion a better API would also be transactional, at the filesystem level. Aside from dramatically simplifying every database, that could also would allow collaborative editing through simple network shares. I don't even think it would be that hard to do.

[moonchild]

> Aside from performance, in my opinion a better API would also be transactional, at the filesystem level

A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)

Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)

0. https://fuchsia.googlesource.com/docs/+/dart-docs/dotdot.md

1. Because plan9 does a better job than unix of making all resources files, inability to access some subset of files is a stronger guarantee.

[imtringued]

I disagree with everything you said because your tone is just wrong. Old APIs don't remove the need for new ones. New APIs don't remove the need for old ones. The existence of one API does not prevent the existence of another API. Phrasing this as an us vs them problem will just waste your time and fail to convince everyone else. Instead of telling everyone how wrong they are you should convince them how great the new thing is.

[pjmlp]

Java File doesn't expose POSIX semantics directly.

In fact, there are special derived classes to handle file system specific semantics, if one feels inclined to do so, but that doesn't mean they work all the time, as JVM runs anywhere.