> I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code.
Wind back 35 years or so and you could have said the exact same thing about COBOL.
COBOL also failed so epically that it soured its entire core idea for decades. (That's just an additional observation, I'm not saying you claimed otherwise.)
I won't guarantee that Go will experience wild success and become an A-list language, but I will guarantee that barring some major change in approach or leadership, it will not fail so spectacularly as to destroy the entire idea of trying to create a language for programming at scale. While HN bitches, Go's penetration into exactly the space I'm describing marches on and has passed critical mass.
I'm not sure by which measure you are determining that COBOL failed epically. I think the likelihood of Java, to say nothing of golang, having the presence COBOL has 50 years after its creation is essentially zero.
COBOL failed epically at its goal of making programming easy for everybody by creating an "English"-esque syntax that everybody could understand. It failed so epically that it has apparently destroyed the idea so thoroughly that you don't remember/realize that it was a first-class goal of the language.
If you go back and read what I said, notice that nobody could sensibly call Java a generalized "failure" either. It specifically failed to create a language that would be something that could be used by large groups of people easily, and to the extent it succeeded it did so with incredibly grit, perseverance, and tons of third-party tools and terribly abortive efforts over the years, and it also did it so badly that people entirely stopped talking about even trying it. This despite the fact that "how do we write programs in companies with hundreds of programmers working on tons of discrete projects" is by any measure a very large use case for programming languages, and that only Go is directly addressing this use case directly is in some sense a travesty. (Others address it indirectly, by claiming that their features that are really intended for code safety or power may also as a side effect have the ability to make big programming teams function well, if they even claim that.)
Wind back 35 years or so and you could have said the exact same thing about COBOL.