>That's a very negative way of saying "that's not my personal behavioral preference"
In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive.
In the grandparent's own words:
>>> i was shocked by that at first too. Then I came to love it.
Stockholm syndrome refers is a victim forming emotional bonding with his or her captor[1]. Which would mean in instances like this, where the "captor" is a voluntary choice of language, the term is used akin to "masochism" (albeit without the sexual element). In essence, saying "the pleasure from use feature x is derived from the pain of using feature x".
Which is why I commented that "Stockholm syndrome" is a needlessly colourful way if saying "I disagree".
No, the meaning was: if someone cannot handle unused things, that someone is screwed. Go will not save him in other aspects which require a little bit of discipline and are not checked by the compiler.
So what you're saying is, there are two kinds of people—those who don't need the feature, and those for whom the feature isn't sufficient?
My personal view on this is that warning the user should be enough. The compiler designer is basically saying: I can't trust developers to fix warnings and it is my duty to protect them from their own laziness by enforcing a certain way of working. This apparently attracts a certain kind of people. I prefer to be the one telling the compiler what to do, instead of the reverse.
I'm with you there, I just was making a snarky comment :-)
That's a very negative way of saying "that's not my personal behavioral preference"
> There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter.
Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghetti code (yes, I know you ultimately end up with code quality only as good as the developer, but some languages do still make the process easier than others)
> If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.
Except it does though, since that's the very behaviour you're complaining about.