In Go, what type are os.Stdin, os.Stdout and os.Stderr, and what belongs on each?

## What they actually are In Go the three standard streams are three package-level variables in `os`: - `os.Stdin` — file descriptor 0, the process's input - `os.Stdout` — file descriptor 1, its normal output - `os.Stderr` — file descriptor 2, its diagnostic output All three have type `*os.File`. That single fact answers most questions about them. `*os.File` implements `io.Reader`, `io.Writer` and `io.Closer`, so the streams can be handed to anything in the standard library that accepts those interfaces — `fmt.Fprintf`, `io.Copy`, `bufio.NewWriter`, `encoding/csv`, `encoding/json` — with no adapter at all. They are not special runtime objects and there is no hidden buffering layer between them and the kernel: a `Write` on `os.Stdout` is a `write` system call on descriptor 1. They are also *variables*, not constants. `os.Stdout = f` compiles and works. This is process-global mutable state, so it is a tool of last resort, but it is why a test can redirect a package's printed output without changing that package. ## Who points them where The program does not open these descriptors; it inherits them. The shell decides what they are attached to before the process starts: - `tool` — all three are the terminal - `tool > out.txt` — descriptor 1 becomes the file; 0 and 2 are untouched - `tool | other` — descriptor 1 becomes the write end of a pipe whose read end is `other`'s descriptor 0 - `tool 2> log` — descriptor 2 becomes the file; the result on stdout is unaffected This is the whole reason the split exists. Redirection and piping act on stdout by default and leave stderr alone, so the convention is fixed for you: **stdout is data, stderr is for humans.** ## What belongs on stdout Only the thing the program was asked to produce, in a form another program can consume: the converted file, the matched lines, the JSON document, the computed number. Nothing else. Every extra byte you print there is a byte the next command in the pipeline has to parse. `tool | jq .` fails outright if a friendly banner precedes the JSON, and `tool > data.csv` silently poisons the file with a `processing...` line. ## What belongs on stderr Everything else a person might read: errors, warnings, progress counters, verbose logging, usage text on a bad flag. Two properties make stderr the right home. First, the shell leaves it attached to the terminal even when stdout is redirected, so the user still sees why their command failed while the output goes to a file. Second, Go never buffers it, so a message written immediately before a crash is already on the screen. ```go n, err := process(input) if err != nil { fmt.Fprintln(os.Stderr, "process:", err) return err } fmt.Println(n) ``` `fmt.Println`, `fmt.Printf` and `fmt.Print` are shorthand for the `Fprint*` forms with `os.Stdout` as the destination. There is no `fmt.Eprintln`; reaching stderr always means naming it. ## Reading from stdin `os.Stdin` is the mirror image: an `*os.File` you can hand to `bufio.NewReader`, `io.Copy`, `encoding/json.NewDecoder` or anything else expecting an `io.Reader`. A filter reads it, transforms, and writes the result to stdout — which is what lets your program be dropped into the middle of somebody else's pipeline without knowing anything about its neighbours. ## Common mistakes - Printing diagnostics with `fmt.Println` out of habit, so they land in the data stream. - Assuming Go buffers stdout the way C's stdio does. It does not; each write goes straight out. - Believing stderr is only for fatal errors. It is for anything human-facing, including routine progress. - Reaching for `os.Stdout` deep inside a library. A library should take an `io.Writer` (or return the bytes) and let the program decide where output goes. ## The practical rule Write it down as a contract before the first release: what appears on stdout is an interface other people's scripts will depend on, and once they do you cannot change its shape quietly. Everything conversational goes to the other descriptor.