Evil Go: Doing Well by Doing Bad
summary
Argues that specific bad choices — bad package names and layering, interfaces defined on the wrong side, passing pointers that mutate structs, turning errors into panics, and hidden configuration — produce brittle, hard-to-reason-about Go systems. Demonstrates the claim by rewriting a small HTTP service twice: first explicit wiring, then using fall + outboy with init and blank imports and a helper panic if err, showing the DI/framework version runs but hides wiring, magic, and failure modes that make maintenance costly.
AI-written summary · about
chapters (15)
- 0:00Introduction and setup
- 1:28Poor packaging practices
- 3:12Evil interfaces and abstractions
- 5:35Pointer passing for population
- 8:03Abusing panic and recover
- 10:10Configuration by side effect
- 12:37Sprinkling configuration everywhere
- 14:02Frameworks versus libraries
- 15:44Evil in dependency injection
- 18:12Good Go example
- 18:33Evil Go rewrite with Fall
- 22:49Seduction of magic code
- 23:31Enterprise patterns in Go
- 24:33Choosing good over evil
- 25:12Q&A and closing
related talks
25mThings in Go I Never Use
30mUnraveling Go Anti-Patterns
29mThink Pragmatically: Elevating Your Go Development Skills
33mClean Up Your GOOOP: How to Break OOP Muscle Memory
22mHigh(er) Reliability Software Patterns for Go
20mBuilding Better Packages
18mGo Lift
33mClean Up Your GOOOP: How to Break OOP Muscle Memory