eprint! and eprintln! for stderr
eprint! and eprintln! are the stderr counterparts of print! and println!. They use the same format-string syntax, but keep diagnostic output separate from the program’s primary stdout stream.
eprint!("warning: ");
eprintln!("retrying request");Why the stream matters
Section titled “Why the stream matters”A command-line program may send its real result to stdout so another process can pipe, redirect, or parse it. Progress text mixed into that stream can corrupt the result.
Stderr gives operational messages their own channel:
stdout -> data or primary resultstderr -> errors, warnings, progress, diagnosticsThe terminal often shows both streams together, which can hide the distinction during manual testing. Redirection and pipelines reveal why the separation matters.
eprint! vs eprintln!
Section titled “eprint! vs eprintln!”The newline rule is the same as on stdout. eprintln! appends a newline; eprint! does not.
Use eprintln! for ordinary diagnostic lines. Use eprint! only when you intentionally want to keep the line open.
Redirection keeps the streams useful
Section titled “Redirection keeps the streams useful”A caller can redirect stdout to a file while still seeing diagnostics on the terminal, or redirect stderr independently for later inspection.
That is why progress text belongs on stderr when stdout is intended to be machine-consumable data. The terminal may merge the visual presentation, but the operating-system streams remain distinct.
Not a logging system
Section titled “Not a logging system”Stderr is a destination, not a logging architecture. These macros do not provide levels, structured fields, filtering, timestamps, or spans.
For a small CLI error message, that simplicity may be exactly right. For durable application diagnostics, use an appropriate logging or tracing layer and decide where that layer writes its output.