Most companies, in my experience, want tools that are easy to get right in 80% of cases, and in 20% of cases require experts. Go has the benefit of most benign work is deadass simple to get right. The things you referenced in your post are obviously the remaining 20%.
Rust, as an example, is a pretty difficult language to become productive in. Sure, once you've invested the time, you're equipped to handle a wider array of problems, but most organizations don't particularly care about the top. They care about becoming relatively productive relatively quickly.
Go's approach to certain problems require expertise, it is not a silver bullet. But there are no silver bullets, and the examples you gave require expertise in any language. The issue is that you've kind of just cherry picked those three concepts as proof of complexity, ignoring the boatloads of other examples in which Go's simplicity does add value.
> Rust, as an example, is a pretty difficult language to become productive in.
Perhaps it's experience with other languages, or the fact that I grew up when that sentence started with C++, but I honestly found rust pretty easy to get up to speed in.
Am I an expert? No, and until I get the chance to use it for a living that won't change. But getting from "I want to do X and Y with this language" to having done so was straightforward enough.
Stripping a language down to the point we can learn it in a week is a bad tradeoff, because we'll never improve after that. The toolbox will always be empty, best treated as a codegen target for abstractions in some more insightful language.
There are plenty of languages that you can go from "Never touched" to "Having contributed something" in a week. Are you saying that those languages aren't productive or valuable?
A language is productive if it reduces the effort to solve your problems. I think some people feel productive as soon as they're able to solve a problem by cranking out a lot of code, but I view that as the language failing to help them.
Totally agree. I never understood as a demerit that go is boring ... like it's some slight to programmer swagger. Most engineers prefer simple. Beginner programmers may screw up go but in my experience it's more a limited gestalt issue: they can't wrangle the requirements, the domain types, code structure (and whether those are in shape or no) ... Consequently they react to the code in terms of how it comes to them.
Rust, as an example, is a pretty difficult language to become productive in. Sure, once you've invested the time, you're equipped to handle a wider array of problems, but most organizations don't particularly care about the top. They care about becoming relatively productive relatively quickly.
Go's approach to certain problems require expertise, it is not a silver bullet. But there are no silver bullets, and the examples you gave require expertise in any language. The issue is that you've kind of just cherry picked those three concepts as proof of complexity, ignoring the boatloads of other examples in which Go's simplicity does add value.