> The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.

That's a rather disingenuous summary given that literally the very first response is Brad Fitzpatrick from the Go team agreeing with you, acknowledging that it's unfortunate, and admitting that it can't feasibly be changed yet due to the compatibility guarantees. And then shortly afterwards, he encourages you to bring this point up when Go 2 comes around.

Actually you seem to be pretty disingenuous by ignoring the rest of the posts and focusing just on the first one. The overall tone of the thread seemed to be pretty dismissive and I doubt if a solution was proposed for Go2 that it would gain any traction.

I doubt that there will ever be a Go 2.

EDIT: For the downvoters, quoting Rob Pike in one of his presentations, "Go's design is done".

Maybe he should have said the design is done for go1.

Regardless, issues are still filed under the tag of `go2`, even by Rob Pike. There's no reason to believe that go2 won't eventually happen.

On the other hand, there's every reason to believe the "Go [a]Way" prohibition on certain language features will leave Go 2 insufficiently attractive vs Go 1 to overcome the switching costs, dragging out any migration period. See also: Python 3.

I remember I reacted hysterically in Twitter about this change, somebody gave me link to your post and after reading first response of Brad Fitzpatrick I realized there's no chance for arguing or discussion - all decisions are final and community feedback isn't required.

This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link).

http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...

I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go.

I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements:

1. If my sense of elegance and the Go team's sense of elegance is this divergent, then the language will probably get uglier to my eyes as it continues to evolve.

2. If this is the reaction from the team to this (relatively small and inexpensive to fix) problem, then we can expect absolutely no movement at all on the bigger and harder problems (dependency versioning, generics). I used to have faith that these very smart people will come up with an elegant solution to these issues - I still love the simplicity and elegance of the standard library - but my faith has now gone.

3. Brad's response was amazing and I'd follow him anywhere, but... I don't want to follow the rest. If I'm to commit my time and effort to learning (and to a tiny extent popularising) the language and being part of the community, I want to believe in the people building it. I don't any more.

Humans are weird.

Agree with 1 and 2. And to clarify my comment: Brad's response is very detailed and I have nothing against it, I just see even Brad can't change things so these things will not be changed by community. I really respect Brad as a programmer.

Never used Acme. The answer always seemed to me weird, like "we are right, we do not care about this."

Just say no is a good slogan for "bad" things but pretending that syntax highlighting is "bad" is senseless.

Most interesting response from Russ Cox: "Where you see a hack I see an elegant design."

Elegant design...

They say that beauty is in the eye of the beholder.

meh.

Yeah. It makes no sense to believe that beauty is completely subjective, yet somehow related to software quality.

It's particularly baffling when, in response to:

> But I disagree that putting commands in comments at all is a good idea. Just because other languages do it doesn't make it a good idea. It's clearly a hack to get around some historical problem, and we're better than that.

A member of the Go team says:

> Where you see a hack I see an elegant design.

It's never been an elegant design, at best, it was an acceptable design in the 90s.

That seems a general attitude from the Golang group. Same argument about generics, etc.

If I had a huge amount invested in Go I would consider forking it - it is one thing to have a benevolent dictator, but if he doesn't at least listen then there is no point at all.

> The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.

I don't see why that's so hard to imagine. Just because someone is skilled/bright in some area doesn't mean that they are skilled/have good taste in another area. Even if those areas are very similar from a high-level view, like both involving programming.

There has been a lot of appeal to authority with regards to the Go designers/developers - basically that they have a long track record of making great/influential software. And though appealing to authority certainly isn't without merit, I think it was taken a bit far, namely that it was used as an argument to try to end all discussion. And secondly the things that they are famous for does not seem to be related to PL/design.

Actually it does. C was shaped to a large degree by feedback from the original Unix programmers, including Ken Thompson and Rob Pike.

Rob Pike? I thought that C came into its shape before his time.