Lectures

Let’s break down how to log correctly in Go CLI apps: why the “command result” should go to stdout, while diagnostics should go to stderr; how the log package’s standard logger works; how to configure output via log.SetOutput, prefixes, and flags ( log.LstdFlags, log.Lshortfile); why to create separate loggers with log.New; and why log.Fatal is dangerous because of os.Exit(1) and “killed” defer.

We break down the basics of log/slog in Go: why structured logging matters, how the Logger → Handler → io.Writer model is arranged, how TextHandler and JSONHandler differ, how the level threshold works via HandlerOptions, and how to centralize configuration with slog.SetDefault. Separately—a practical approach for CLI: stdout for results and stderr for diagnostics.

We break down how to turn “just plain text” messages into structured events in log/slog: we fix a minimal key dictionary ( operation, id, duration), learn to choose stable values for scenarios, correlate logs by an entity identifier, and measure execution time via time . Since ( start ). At the end, we wire these fields into a simple CLI todo app and go over common mistakes.

We’ll go through a practical logging policy in Go: why you shouldn’t write logger.Error in every function, where the application “boundaries” are (CLI: main()/ run(), HTTP: handler/middleware), how to add context via error wrapping with fmt.Errorf ( "%w" ), and how to avoid duplicates using the rule “one problem — one Error log”.

We cover practical logging “hygiene” in Go: why logs are not fmt.Println, how to prevent leaks of secrets and personal data, why to redact tokens, how to use Debug/ Info/ Warn/ Error levels in log/slog in a disciplined way, why structured fields and stable messages matter, and how not to break the CLI contract: results go to stdout, diagnostics go to stderr.