I'm a big advocate for simplicity. I think it's one of the most important guiding principles in software engineering. I don't care for Go mostly for reasons unr

I'm a big advocate for simplicity. I think it's one of the most important guiding principles in software engineering. I don't care for Go mostly for reasons unrelated to its simplicity; I have respect for the latter, even for decisions like excluding generics. I think broadly that we need more simplicity-focused languages. However, I find that simplicity's most vocal advocates often go off the deep-end, dismissing extremely productive technologies and practices simply because they appear complex when viewed from a certain angle. To use the author's own quote: > There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity. Nothing is a cure-all. That includes a relentless focus on simplicity. If your language is minimal, it probably means you're going to have a lot more complexity in the code itself. Maybe that's worth it, maybe it's not. There's also no hard line between accidental and intrinsic complexity; the goal-posts shift when things get generalized at the language or library or service level. Both the complexity of the holistic system, and the complexity of what you and your team actually need (or don't need) to manage yourselves, have to be considered. In short, the landscape is more complex (no pun intended) than the ideology represented here.