Whenever I see Go I think of this:
And if you think I‘m sarcastic, we might have a different belief system underneath: For me the irreplaceability of an engineer is not measured in the creation of complexity and the mastering of technical acuity in a language that‘s hard to grasp — but much more about the value and delight any piece of code brings to its users through simplicity.
A language that is fast, easy and simple by default and doesn‘t get in the way of people trying to build something for the first time is a feature, not a bug.
My main gripe with Go is it doesn't seem geared toward figuring out new things, or letting people hack and experiment during development.
I came to Go from Ruby (and Python too, but I mostly used it before 2.7) and soon enough all my hacks and "let's try it this way" projects were in Go.
>It doesn't yell at you for having unused variables which is nice for actually developing the software.
No it is not. That was my first impression too but after a few weeks you understand that this was just a bad habit. Not a practice.
My main job for the past 5-6 years is system integration and I had a chance to compare Ruby and Go in this field.
And this is definitely where I'd prefer Go to most other languages. You don't need clever code most of the time, you need really clear and safe code that will run for a decade after deployment.
The question which language makes it easier to write such code (assuming it still should be readable and maintainable, even by the new employees, even if they are not familiar with all the tech behind it)
But I agree that Go doesn't offer a lot for people who like to fiddle around endlessly with the language features - OTOH this allows you to concentrate on the thing you should be fiddling with, which is the actual implementation.
And what about making it easy for them not to make mistakes?