Is Go's os.Stdout buffered, and what changes when you wrap it in a bufio.Writer?

## Go's answer: no buffering at all `os.Stdout` is an `*os.File`. Its `Write` method calls `write(2)` on descriptor 1 and returns. There is no library-level buffer, and - importantly for anyone arriving from C - no behaviour that depends on what stdout is attached to. C's stdio line-buffers when stdout is a terminal and block-buffers when it is a pipe, which is why a C program's output pattern changes the moment you pipe it. Go's does not: it is the same, unbuffered, in both cases. That is a deliberate simplicity trade. You never get surprising interleaving or a lost tail by default, and you never need to reason about a mode you did not choose. What you get instead is one syscall per `Write`. ## What that costs A syscall is on the order of a microsecond. Printing one line per record with `fmt.Println` means one syscall per record, and for a filter processing millions of records the process spends most of its time in the kernel doing tiny writes. This is the single most common reason a Go CLI is slower than the equivalent shell pipeline. Note also that `fmt.Fprintf` formats into a temporary buffer and issues **one** `Write` per call, so the syscall count tracks the number of print calls, not the number of format verbs. ## Wrapping stdout ```go out := bufio.NewWriter(os.Stdout) defer func() { if err := out.Flush(); err != nil { fmt.Fprintln(os.Stderr, "flush:", err) } }() for _, rec := range records { fmt.Fprintln(out, rec) } ``` `bufio.NewWriter` allocates a 4096-byte buffer; `bufio.NewWriterSize(os.Stdout, n)` picks another size. Writes copy into the buffer; when a write does not fit, the buffer is flushed to `os.Stdout` and filling resumes. A single write larger than the whole buffer is passed straight through to the underlying writer rather than chopped up, so an undersized buffer is a performance question, never a correctness one. Syscalls now scale with total bytes divided by 4 KB rather than with the number of lines - typically two or three orders of magnitude fewer. ## What you take on **The flush is yours.** `bufio.Writer` has no `Close` method. `os.Stdout` knows nothing about your buffer. Nothing in the runtime will empty it. If the function returns without `Flush`, everything written since the last spill - up to a full buffer's worth - is simply never written. The output looks *almost* right, which is what makes it a nasty bug: the file is short by a few kilobytes at the end. **The error moves.** `bufio.Writer` records the first write error and keeps returning it; the individual `fmt.Fprintln(w, ...)` calls mostly just copy bytes and succeed. The real `write` to descriptor 1 happens on a spill or on `Flush`, so a checked `Flush` error is the only evidence your output actually landed. A disk-full or broken-pipe condition shows up there. **Ordering becomes your problem.** If some code writes through the wrapper and other code writes directly to `os.Stdout`, the two streams of bytes interleave in an order that has nothing to do with program order. Pick one writer for the stream and pass it down. ## When not to buffer - A program that prints a few lines and exits: the wrapper adds a flush obligation and buys nothing. - An interactive prompt: buffered output can leave the prompt sitting in memory while you wait on input, so a prompt written through a buffer must be flushed before the read. - `os.Stderr`: leave it unbuffered. Diagnostics are low volume and you want them out immediately. ## Sizing 4 KB matches a typical page and is fine for almost everything. Tens of kilobytes can help a very high-volume filter, with quickly diminishing returns; megabyte buffers mostly increase how much output is in limbo if the process dies. Measure with a benchmark before changing it. ## The rule to carry away Go gives you no buffering and no surprises; adding a `bufio.Writer` is a deliberate trade of one syscall per line for one flush obligation you must honour on every path out of the function that owns the writer.