Why is stdout faster than stderr?
blog.orhun.dev
blog.orhun.dev
POSIX doesn't govern Rust at all.
https://github.com/rust-lang/rfcs/pull/899
Still, no real discussion of why unbuffered stderr.
Stdout is generally the "normal output" so loss of information on crash tends to be less relevant, and throughput more so as programs commonly send huge amounts of data to stdout.
Notes
The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed. This can produce unexpected results, especially with debugging output. The buffering mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call. Note that in case stdin is associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (Indeed, normally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcsetattr(3); see also stty(1), and termios(3).
> Initially, the standard error stream is unbuffered.
coreutils has a very hairy program called stdbuf which can change the line buffering of an existing program. It uses LD_PRELOAD(!) to preload a library which overrides the program's defaults.
Ummm no. This is completely backwards. Stdout isn’t character special if it is pointing to a disk file. And they are hung up on a Linuxism here to boot (the proc symlink). The whole world isn’t Linux and I have never heard of this definition of character special, so I wonder where they found it. Of note, FreeBSD realized the whole block/character distinction was dumb, even block device modes are “character special”.
Author is very confused about the ontology of file descriptors and files, and device nodes. Sure it’s confusing to a newcomer but there are plenty of well written guides on the topic.
Too verbose, too Linux centric and too inaccurate.
And scrolling through nothing new than what is well trodden ground https://stackoverflow.com/questions/37991116/why-is-stdout-b...
Tl fucking dr, stderr is not buffered by default in rust.
Yeah, other than the most popular Unix like desktop OS being macOS and iOS a dominant second in mobile. Other than those two that no one uses, most of the world is Linux. And for the topic at hand the macOS design is basically same as FreeBSD as mentioned, macOS is not derived from Linux.
No one started off with a claim that Linux isn't the majority of Unix like systems, how you get that from "The whole world isn't linux" is beyond me.
macOS and iOS are heavily used Unix like systems with significant market share. They're not rounding errors.
> Most computers are not desktops.
Doesn't fucking matter, Mac OS software is still a multi-billion dollar industry.
> Most phones
iOS is about 30% of the market. Yes 70% is a majority, but not an overwhelming majority whatever that is, especially when that 30% pays the bills more than the other 70%
If you're going to pull the irrelevant pedantic shit it helps to be right too, the overwhelming majority of computers are not running Linux since for every crappy Android phone out there, there are dozens of embedded devices running some variety of RTOS. And is a Nintendo Switch a phone or a server?
The stackoverflow link is irrelevent -- it is a question about C. Rust's stdlib and implementation of stdout/stderr buffering is wholly unrelated to the one in C.
They're not wholly unrelated, they are related. The rationale for the implementation in both cases is the same (whether it is good, nonwithstanding). There are stack overflow questions related to the rust implementation, I selected a non rust to illustrate it's more than some rust specific implementation detail that occurred in a vacuum.
Unpopular opinion: It is still good to learn enough C + system programming & their gotchas before starting with a more fancy higher level language.
And easier
I went from very high level (C# web and even webassembly) to C
and while I believe I learned a lot and my understanding of computers improved,
then I think the biggest lesson is that one of the most important programming ecosystems (C) is a very messy and painful.
Not because it must be painful, but because of decisions made decades ago, maybe some inertia, maybe backward compatibility, maybe culture, who knows?
Low quality compiler messages, ecosystem fragmentation, terrible standard lib (where are my basic datastructures), memory management being minefield, etc.
There's a lot of unfamiliar territory, but I'm really enjoying it. When it's complex, it feels like it's just inherently complex. Which is a breath of fresh air for a web developer. I'd gotten so sick of the bullshit complexity that comes along with the high-level work; programming feels fun again.
C has a standard library which students should understand even though it's making system calls deep down. Rust has a standard library which students should understand even though it's making system calls deep down (in fact, sometimes through the host C library).
I certainly see the value in knowing C and Unix and that was my education over two decades ago as well. But I also watched many people quit computer science altogether because they struggled with heisenbugs with C pointers. If they could have been kept on track by Rust compiler errors and higher level abstractions, maybe they would still be in the industry today, learning whatever else they needed instead of quitting in their first semester.