Well, since the people behind Go did not up front say anything about the language/compiler being specifically targeted at 64-bit platforms, I would expect someone more mature from the Go team to step up and say something like "We are sorry, we didn't foresee the consequences of some design decisions and hence screwed it up." and either "We will fix it ASAP" or "We cannot fix it because XYZ". They might not take money for their work directly from the users, but there is still some moral obligation if you create something, release it to the world, praise its virtues and persuade people to use it. As it can be seen in the thread, lots of people already invested lots of time into building things with Go and now they're in serious trouble. Instead, many people in this thread try to somehow downplay the problem, advocate changing hardware (that's something quite new in the programming language world) or following some pretty absurd guidelines. This might or might not be representative of the whole community around Go, but it surely leaves a bad taste, hence the slight irony.
There is an "official" response: the post references a bug # where Russ Cox said "the rest of the issue will have to wait until after Go 1".
Note that Go 1 is a "language freeze", not the implementation freeze.
Now that it's known there's a bug that will be worked on later, people proposed possible workarounds, the easiest of which is to switch to 64-bit platform. I agree that downplaying the issue is wrong, but only one person did that.
There is occasional rudeness, mostly caused by strong opinions, but overall I think Go community is pretty good.
The very next sentence in this response from Russ Cox is: "Or maybe all the 32-bit systems will be replaced by 64-bit ones.". So, they do not admit this is a serious problem that needs attention, it is not clear whether they will fix it, when they are going to fix and whether anyone cares about fixing it at all.
I couldn't find the adequate words to express this so far, but the reason I at all find this situation worth commenting on is that is reassembles to me a very common pattern of denial I observe among many professionals in various professions in cases where a problem appears that is very hard to tackle or even to analyse in the first place. Often a doctor who has troubles identifying a disease will tell you it's probably just something in your head, a programmer who has trouble reproducing a difficult bug will tell you it's you who probably did something wrong at some time, even a guy who I called to repair my washing machine that was stopping the washing at random told me to "keep it under observation" when he wasn't able to tell what's wrong. Many people simply do not want to put in the work needed to solve an unexpected and difficult problem, and thus, perhaps even subconsciously, try to handle it by pretending it doesn't exist. If you want to be a real professional and a leader in what you do, you can not behave like that, you can not repress a problem when someone reports one to you, you have to have the patience to examine the issue, the experience necessary to know when you can be certain that you have the complete picture of it, then sometimes the courage to admit there really is a problem and then finally you have to solve it, or people will not respect you.
I don't think Russ denied it was a problem, so I don't think this is a "pattern of denial". I think you're incorrectly interpreting that statement as his "fix" for this bug.
The fix is well-known (a precise GC), just implementing it hasn't happened yet.
