and:
"I also don't like Go much, but it's not because it challenges my identity"
You are EXACTLY who the article is talking about. One of Go's selling points is maintainability. Go's inherent bias towards maintainability challenges your identity.
and:
"I also don't like Go much, but it's not because it challenges my identity"
You are EXACTLY who the article is talking about. One of Go's selling points is maintainability. Go's inherent bias towards maintainability challenges your identity.
Go's users and designers make all sorts of claims about it. As it happens, I've evaluated them and find that I often disagree with them.
For instance, Go projects often don't specify the versions of their dependencies and choose to just clone the code into their own source tree instead - if you're lucky. If you aren't then the project simply depends on whatever is found in the dependencies git master branch. I find this to be poor practice from several perspectives, maintainability amongst them.
except when talking about maintainability, you are not talking about facts. Show me the "fact" that Go is hard to maintain.
The language is, honestly, too young to have much "rubber meets the road" legacy code for anyone to make a strong evidential case with. It's all theory until a decade from now.
(Note: I'm not arguing for or against this point; I've never used Go, so couldn't possibly know)
I don't think Go was intended to improve upon any Lisp deficiency.