When I think about tooling, I'm thinking about things like build systems and dependency managers. In Go, I don't need to script my own build system like I would

When I think about tooling, I'm thinking about things like build systems and dependency managers. In Go, I don't need to script my own build system like I would do in C, C++, Java, etc. Similarly, reproducible package management works out of the box--I don't need to try in vain to get the right versions of the right dependencies installed to the right locations like I do in C and C++ (and Python, to a lesser extent). Moreover, Go produces native static binaries out of the box by default--I don't have to cobble together a bunch of configuration in every one of my projects only to have it broken by the odd transitive dependency which can't be statically compiled (well, this is probably the case in some Go packages, but I contend that it's far rarer than in the Java, Python, Rust, etc worlds--certainly I've never run into this in my decade with Go). Further still, in Go, I don't have to write CI pipelines to build and publish code packages nor documentation packages. And then there is the toil reduced by having good performance. I have about 15 years of experience with Python, and almost invariably there's some hot path in the code which needs something between Python's level of performance and Go's level of performance. Unlike Go, Python affords relatively little headroom for optimization--you can't easily parallelize anything or pull some allocation out of a tight loop for a 10x performance gain. Usually this looks like rearchitecting your codebase so that "rewrite the hotpath in C/multiprocessing/etc" is attainable and on top of that you're probably implying significant changes to your build system and/or runtime environment as well as a load of maintainability problems associated with anything that touches the language/process boundary. By comparison, I think the gains from generics are relatively small.