In my experience as a professional Python dev and a hobbyist Gopher, Go's libraries are a lot less convoluted than Python libraries. In Python, you see a lot of libs that try to do everything for everyone (think long args lists and functions that try to guess the right thing to do based on arg types) whereas Go libraries just kind of snap together neatly. Go tends to be more productive for me than Python specifically because its philosophy values simplicity and orthogonality over complexity and scope breadth.

> Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

Sequentially, Go outperforms Python and other interpreted languages by a wide margin (usually a factor of 10). Things get really interesting with Go because it can be massively concurrent without messing around with large async refactors. At work, we're hoping our first iteration (i.e., before any async refactors) of our Python application to handle something like 5-10 concurrent requests per machine (without degrading response times), but I'm confident a single Go process could handle at least 10X that load with better response times. This order-of-magnitude difference seems fundamentally different from the perspective of "throwing hardware at the problem". Further, Go's library story is fairly complete (for web services; GUIs and other domains are still lacking)--at least it's been a long while since I've lacked a complete library for some task.