Discussion
Lots of Unix style tools (ab)use stderr for non-error output, just to avoid mixing informational bits with other things in stdout or for separating machine-processable output from what is meant for humans.
A lot of Unix ideas were based on explicitly bringing humans close to the system though, being heavily based on text.
I think the semantics of those two streams, stdout and stderr, are outdated.
Does it make sense for the OS/runtime to provide specific log levels / semantics anyway?
@bms heh I am somewhat involved in Plan 9 things 🤫
In general, I'm really thinking about it.
Have been for a long while, anyway.
The basic idea of per-process namespaces in Plan 9 is somewhat neat, though I want to get away from making everything look like a file, but actually causing side effects that "one just has to know"; it's the weirdest kind of an API.
OTOH, I am currently running into some annoyances (again) with a tool I'm building that needs to call into other tools. 🙃
@CyReVolt Plan 9 is fine modulo Timothy Roscoe's criticisms of it, and I touch upon this in unpublished cybersecurity monographs. I aimed to do some of what you proposed for AmigaOS in a long ago chapter of life.
The thing is, spawning another tool and parsing its output is super non-ergonomic.
The best that can happen is some form of structured logging, such as linewise logging.
Having to look at status (exit code) and two streams still feels weird. And it's always specific to what tool is spawned.
@CyReVolt You propose to reinvent Macintosh Programmers' Workshop from the 1980s, and Plan 9 from Bell Labs? /s
GET RIGHT OUTTA TOWN /s