I/O Stream Abstractions

WHY IT EXISTS Reading and writing happen against wildly different backends: disk files, TCP sockets, pipes, memory buffers, encryption and compression layers. Without a shared abstraction, every consumer would special-case each backend. Stream interfaces give one uniform contract so code written once works against all of them.

THE MENTAL MODEL Treat data as a one-directional flow of bytes rather than a fixed blob. A Reader is anything you can pull bytes from until it signals end of input; a Writer is anything you can push bytes into. You never hold the whole payload; you move chunks through, which keeps memory bounded regardless of total size.

HOW IT WORKS Go's io.Reader has one method, Read, that fills a caller-provided byte slice and returns the count read plus an error, with io.EOF marking the end. io.Writer has Write, which consumes a slice and returns how many bytes were accepted. Because these are single-method interfaces, decorators wrap them: a gzip reader wraps a file reader, a buffered reader wraps a socket. Helpers like io.Copy move bytes from any Reader to any Writer in a loop with a small buffer, never materializing the full stream.

WHEN IT MATTERS It matters for large or unbounded data, for composing transformations, and for testability. You can swap a real network reader for a strings.Reader in tests, chain compression and encoding as wrappers, and stream a multi-gigabyte file through a fixed buffer.

ONE CONCRETE EXAMPLE To decompress and parse a large gzip-compressed JSON file, you open the file as an io.Reader, wrap it in a gzip.Reader which is itself an io.Reader, and hand that to a json.Decoder. Bytes flow file to gunzip to decoder in small chunks, so a two-gigabyte archive parses with kilobytes of working memory, and the same decoder code works unchanged if the source becomes an HTTP response body instead of a file.