That's what cargo/rustc do: all of the information is conveyed through text, but colors are used to make it easier to scan. It ends up using almost every usable base-16 color: red for the error marker and their primary spans, yellow for warnings and their primary spans, blue for secondary spans, the gutter separator and line numbers, bold text for the main message, cyan for notes and their primary spans, green for helps and their primary spans, green and red for structured suggestions, bright magenta for very specific hand-picked highlights (used to be bold/bright white, but that wasn't obvious enough in lots of terminals, used semantically equivalent to bold or italics in text, the case most people will encounter these in is in E0308 type errors where a specific type parameter didn't match) and white for anything else. Note that of the mentioned output the only thing that is differentiated in color only is the message highlights, and that's because it is generally done for either extra clarification ("Trait is not implemented for Foo, but it is implemented for Bar") or within code that we wouldn't want to pollute with additional non-code ASCII markers (people should be able to copy&paste those types without causing parse errors). Some people deride this variety as being too "christmas tree", but IMO it works quite well for scanning output. Color helps a lot when scanning longer lists and dense output. Colors might not help much if the tool is emitting a single line of output for each event, but rustc emits dozens of lines per error. And no, reducing the amount of output would not be the answer for rustc, you can already use `--message-format=short` if you want that, or try/contribute to one of the TUI projects consuming the json output for dynamic navigation of the output (to expand and contract sections). rustc and cargo default configuration have to cater to the most common case, while also keeping the number of non-essential features (like a built-in TUI) to a minimum.