I believe there’s always a cost to managing the complexity and the complexity never diminishes. It depends on whether you are efficient at managing it that way

I believe there’s always a cost to managing the complexity and the complexity never diminishes. It depends on whether you are efficient at managing it that way or another. Go doesn’t give you many tools to control it but forces you to certain behavior while developing the code. If you are strict about your code structure and the use of certain perhaps untypical design patterns, then you’ll be fine when the code base grows large. There are well-managed C projects that thrive. But they solve specific problems and to them they do lend well. For other kinds of projects the cost of managing the complexity that way might become prohibitive. Go is well-suited for such problems that the HashiCorp stack solves. But Vagrant has a Ruby code base. Many similar tools were written in Python. Gentoo Linux package manager is Python. Homebrew is Ruby. The complexity of your specific problem distributes itself unevenly across all knobs and bolts of the development process. Some teams tend to manage Python code bases more efficiently, while others might prefer C++ over Rust. Some languages have libraries available that take away a lot of complexity from your immediate control by solving some part of your problem—you delegate it in the hope that it’s managed properly over there.