Hector Martin

Anyway, the reality is we *don’t* use processes and pipes for important things, *because* they fail roughly like this. You can say “but error codes” all you want, we don’t do this with browsers or ssh or gzip or REPLs (hello, Jupyter) or anything else. Because this hits a wall.https://twitter.com/marcan42/status/996231278276919296 …

You can say it shouldn’t matter. But it really does. It’s nice to have Unix process management, it’s great to be able to lash things together with stringly types blobs, but eventually, we always move from pidgin to creole (to borrow phrasing from actual linguistics).

So how are process exit codes different from shared library return codes different, exactly? What makes it more likely that a stupid user will not check the former but will check the latter? Your argument is valid, but *this bug* is not a good example against processes and pipes

No, that’s what you’re not getting. It really is the fragility of the interface that gets you the “It returns content by default, hope you’re smart enough to check the error code, what do you mean nothing did” surprise not surprised dynamic

Again, that "it returns content by default" is a *consequence* of the streaming design of the interface. It would be *exactly the same* as a shared library, with that design constraint. You'd end up with a "more data" callback getting called before the main entry returns error.

I mean, look, you have the same failure mode all over the place so the bug is in the interface. API plus developer equaled insecure code. Thems the breaks. You could make a case the streaming API is the issue and not pipe vs shared lib. But then the streaming API deprecates.