> Surprisingly, Rust, as of now, uses line buffering for both TTYs and non-TTYs.
> The FIXME comment shows the Rust team acknowledges that ideally they should check if something is executed in TTYs or not and use LineWriter or BufWriter accordingly, but I guess this was not on their priority list.
This does not inspire confidence.
In libc, you can use setvbuf to change the buffering mode.
How would a modern OS implement this?
Probably by not assuming terminals and byte streams any more. Terminal-by-default is a 20th-century-ism. Now you have screens with pixels. Without stdout, no need to know if stdout is a terminal.
This is an interesting idea--that in a reimagined OS, programs could have their output connected to all sorts of sinks (terminal, file, GUI, web content) without carrying baggage related to those sinks' behaviors.
I think the core question is whether some middle layer of output processing between program and sink/display could be created that knows enough about (using terminals as an example sink) raw mode/console dimensions/buffering to make most programs display correctly enough for most users without knowing specifics about the program writing the output's internals. If that can be done, then programs that need more specifics (e.g. complex animated/ncurses GUIs) could either propose overrides/settings to the output middleware or configure it directly, and programs that don't wouldn't.
That's possible to implement, sure, but can that be done without just reinventing the POSIX terminal API, or any one of the bad multiplatform-simple-GUI APIs, badly?