In Go's log/slog, why does the order of Logger.With and Logger.WithGroup change the output?

## A logger is a value, not an object you mutate `Logger.With(args ...any) *Logger` and `Logger.WithGroup(name string) *Logger` both build a **new** logger. The receiver is left alone. This is the first thing to internalise if you are arriving from a logging library where you configure a logger in place: `logger.With("dir", d)` on its own line does nothing at all, because the derived logger that carries `dir` was thrown away. The practical shape is therefore assignment or chaining: `logger := logger.With("dir", dir)` inside a function, or a package-level constructor that returns a component's own logger. Since the parent is unaffected, handing a derived logger to another package is safe — nothing that package does to it can change what the rest of the program logs. ## Order is preserved, and it is the whole story A derived logger records the operations in the order they were applied. When a record is written, the attributes and the group openings are replayed in that same order. A `WithGroup` opens a namespace **at its position in the chain**, so it can only affect what comes after it. Attributes attached before it are already placed at the level they were placed at, and no later call can retroactively move them. That gives the two arrangements distinct meanings: - `base.With("dir", d).WithGroup("gen")` — `dir` at the top level; everything logged later inside `gen`. - `base.WithGroup("gen").With("dir", d)` — both `dir` and everything logged later inside `gen`. And there is no closing operation. Once a chain has opened a group, every attribute added afterwards is under it, including the key/value arguments of individual `Info` and `Error` calls. Nesting a second `WithGroup` goes one level deeper. If you need something back at the top level, you keep a reference to the logger from before the group was opened and log through that one. ## Using the ordering deliberately The rule turns into a simple design guideline: **attributes a consumer queries on go before the group; attributes that describe one component's internals go after it.** Consider a code generator that walks a package tree and emits files. A run identifier and the target module are things every dashboard and every search filters on, so they belong at the top level, attached before any group is opened. The per-stage detail — which directory is being walked, which file is being written, which declaration is being emitted — is only meaningful in the context of that stage, so the stage opens its own group and attaches its detail after. The result is records whose top level is stable and small, with a predictable sub-object per stage. The ordering rule is also the fix for a subtle mistake: a component that opens its group first and *then* attaches what it thought were global fields will bury those fields inside the group, where the query that looks for them at the top level finds nothing. The record is present, the field is present, and the search still misses — which is a much more annoying failure than a missing log line. ## What to watch for in review Three things are worth flagging when reading a diff. A `With` or `WithGroup` whose result is discarded, which attaches nothing. A group opened early in a constructor followed by attributes that were meant to be top-level, which buries them. And a chain long enough that a reader cannot tell what level a given attribute ends up at — at that point the honest fix is to build the logger in one place, with a comment naming the intended record shape, rather than deriving it incrementally across several files.