> The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily.
I don't think this necessarily follows. I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go just as easily as other, more expressive languages. In fact, I think it's more likely in Go simply because you _have_ to write more code in Go. More code is more maintenance. Go encourages you to repeat yourself and to not create / use abstractions. Nil pointers are still a thing. It's incredibly easy to accidentally shadow a variable and not handle an error. These are all solved problems in other languages, yet they persist in Go, and they are all maintenance headaches.
> I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go...
It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory. Fancy abstractions for simple use cases is a common cause of tech debt IME, and harder to unwind than under-abstracted code (tedious as that is to fix).
> It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory
Yep, but here's the thing - if the problem is misuse of the tool, then the solution should be to not misuse the tool. Saying "we will remove features because some people misuse it" is like saying "we will remove headlights from cars because some people drive irresponsibly[1]".
Go remains my language of choice if I have to build efficient webservices, but I really feel sad when people make it sound like Go is awesome because it misses language constructs. No! It is awesome because it is FAST (quite near C) but it is very easy to do simple things like writing http servers, parsing JSON and so on (like Python et al).
I don't think this necessarily follows. I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go just as easily as other, more expressive languages. In fact, I think it's more likely in Go simply because you _have_ to write more code in Go. More code is more maintenance. Go encourages you to repeat yourself and to not create / use abstractions. Nil pointers are still a thing. It's incredibly easy to accidentally shadow a variable and not handle an error. These are all solved problems in other languages, yet they persist in Go, and they are all maintenance headaches.