Golang is the new Java. Google designed it for legions of corporate systems coders. It is ultimately destined to be seen as the enterprise language that it is [twenty years ago all the cool kids loved Java]. Google policy is no map function for you, it's just more palatable to bake it into the language than an HR document...it's still pure policy steeped in pointy haired logic.
Don't get me wrong, it's better than it could be: at least it doesn't have something equivalent to UML diagrams. But it's still a corporate policy. It just feels refreshing because...wait for it...it brings garbage collection to C++ programmers. And where have we heard that before?
But with a statically-compiled executable that skirts all the problems with java classpaths and JARs and makes deploys trivial. It's almost like engineers at Google wrote a ton of Java, realized it's faults (along with being sick of paying patent ransoms to Oracle) and wrote a language that was similar but addressed the major pain points for them.
Maybe, in the sense that Go is designed for the use case of large teams of everyday coders (i.e., not PL enthusiasts). A similar use case to Java, no doubt.
That said, Java (and C#, which is where my experience lies) are fundamentally bureaucratic languages. Things like hierarchical namespaces and several layers of accessibility very much mirror their human-org counterparts. Explicitly implemented interfaces are a way of saying “I comply”.
Go, by contrast, is much flatter. Which, perhaps, is where organizations are heading. And interfaces are implicit, which is a way of just doing the job instead of declaring compliance.
I also feel the same. I pulled src code of OpenJDK and Go. JDK code is sprawling over 1000s of directories and deep hierarchies and so many folders just to contain other folders. Go code looks far more cleanly organized.
I wonder if you have taken the time to use Go. I no longer use it but I found it much more enjoyable than C++. I went back to Python for my side projects.
On the one hand, I was responding to the Atwood's law reference. On the other hand, I have become interested in the way corporations use open-source as a strategy and implement that strategy tactically via sort of "basic fighter maneuvers" energy management discipline. [1]
Incipient potential competitors who adopt Go draw a dependency on Google because for all practical purposes, Google will determine the direction of Go: it's core team works there. And incipient potential competitors have radically different needs.
We can differ in opinion upon whether Unix was seen an ATT operating system. For me the legal and licensing histories suggests that it was in a strong sense and the "Open" and "Free" and "Li___" are the heritage.
Go is an incremental improvement over the C++ ecosystem without all the legacy baggage.
By controling the platform, Google can leverage the ecosystem to attract and cherry-pick early adopters to the language.
Once the language becomes populat enough that the Enterprise starts to adopt it, Google will already be onto their next 'ground breaking' technology.
Once people settle on a perception they tend to hold on to it for life. One day soon people won't want to use Java. It'll be seen as "our Dad's language". Steve Yegge (ie now a Googler)
said as much during his OSCON 2007 talk.
The value isn't in the language/platform, it's the people who adopt/build/use it.
Microsoft knows this, developers are what kept them afloat during a decade of stagnation in product development. Oracle thought they could buy their way in by acquiring Sun; except, while they were busy suing Google, Amazon sprinted ahead of the pack with their cloud services platform.
This is how the biggest players make long-term investments. Guarantee an abundant stream of top tier talent and success will follow.
Strategically, the hiring pipeline for Google doesn't matter. It can train new hires in Go or whatever, it's historically hired around non-language competencies to some degree. What matters is being able to introduce breaking changes by leading the development effort and hosting critical repositories: e.g. 1.4 broke subrepository references by changing locations.
Strategically, incipient potential competitors have a dependency on Google and those little breaking changes means that Google can add friction to their development pipeline. Google will, even if it didn't say so on the package, Angular 1 vs. 2 is an example of how willing Google is to leave developers in the lurch and create ecosystem FUD...think of all those now dubious tutorials and "should I wait" forum questions.
I don't think its just happenstance that Erlang allowed Whatsapp to become an existential threat to Facebook with a handful of engineers. Language stability matters for startups more than the big boys.
Go is an incremental improvement over the C++ ecosystem without all the legacy baggage.
Go has little to do with C++, it throws away many useful features (generics, const-correctness, RAII). Also, where C++ encourages reuse of existing C libraries, Go 'penalizes' it by making C calls expensive and placing restrictions on interaction with C (e.g. you cannot store pointer to Go data structures). There are reasons for doing this, but all these things make Go pretty much unacceptable for people who are in C++'s niche.
If Go can be compared to any language with traction, it's the later Pascal family of languages (Oberon) and Java pre-generics. It even makes some of the same mistakes (first no generics, then probably retrofitted generics).
Even if this were true, would it be a bad thing to address some of Javas shortcomings like notorious boilerplate, 100 different ways to package & run your app, multiple seconds to boot up, and "write once, run nowhere"? Many go apps are command line tools, the kind of things people avoided using java for, and where GC does not apply.
Don't get me wrong, it's better than it could be: at least it doesn't have something equivalent to UML diagrams. But it's still a corporate policy. It just feels refreshing because...wait for it...it brings garbage collection to C++ programmers. And where have we heard that before?