Nothing changed. The complete list from the linked PDF:

  - web servers
  - web browsers
  - web crawlers
  - search indexers
  - databases
  - compilers
  - programming tools (debuggers, analyzers, ...)
  - IDEs
  - operating systems (maybe)

Of that list, "web servers" and "search indexers" are both the kinds of "large server software" mentioned by Rob in this paper. (Most Google programs are effectively web servers of some kind, even if they don't speak HTTP directly.)

Sorry if our "positioning" of Go is a little confusing at times. We're programmers, not marketing people. We didn't set out to "market" Go at all, and had we set out with a clear message from the beginning we might have done a better job at it.

This paper best describes the initial motivation for Go's existence. However, like any general purpose language, its uses extend well beyond its design goals.

Thanks for your reply!

Go was originally presented as a language for servers, system software, and application programming. The last two were what got me excited, because server-side languages are already well represented, but there's not many languages you could consider writing a web browser or an IDE in.

However, from my perspective, Google refocused Go exclusively on server software. For example, at Google I/O 2011, the talk was "Writing Web Apps in Go." and in 2012, Go was organized under the "Cloud platform," and Rob Pike's talk was about "high performance network services." Support for Go on App Engine appears to be a higher priority than fixing its known problems on 32 bit. Rob has also discussed how he was surprised that Go attracted more interest from Python and Ruby programmers, who mainly work on server software, than from C++ users (and had some not-very-kind words to say about C++ users). These are some of the reasons I'm discouraged about Go's future as a systems and application language.

In the end I guess you give users what they want, and if Go is mainly interesting to people writing servers, so be it. Keep on rockin' (but I reserve the right to be disappointed).

You're reading tea leaves.

The Go team are not a homogenous group of programmers who can do anything. Each of us has our own particular areas of expertise. That's one of the reasons we work so well, but it also means that prioritizing tasks is complicated. Without going into it too much, the idea that we prioritized App Engine over "the 32-bit issue" is a nonsense.

Incidentally, that issue, to the extent that it was experienced by some users, will be resolved entirely in Go 1.1. This is timely as a lot of interest has developed in the ARM port recently.

Rob Pike's talk at I/O 2012 wasn't about "high performance network services," it was about concurrency. Network servers are a familiar context in which to understand concurrency problems.

There's no "refocusing" going on. It's just that we're putting our best foot forward, and right now that's in server programs and tools. Writing applications (and I'm assuming you mean non-web applications) requires good UI toolkit support. That's not something we're working on, but it is something that others in the community are doing. We all believe Go will make a wonderful language for writing native apps, it's just not there yet. (And I suspect Rob does in particular, having built Inferno with Limbo, which used Go-like concurrency to great effect in its UI APIs.)

It will come.

The reality is that people working on non-google projects keep leaving because the community is being shaped by some toxic personalities. We get hooked by the evangelism, buy the party line, build a proof of concept, become disgusted with the community, leave, and concurrently realize that C++ is the way forward.

Wow, you are the first such example I've heard of. Please email me [email protected]. I would be very keen to hear about your experience with the community.

No thanks, Andrew. I've already contributed enough and I really don't think I owe your company anything at all.

I find it rather rude to publicly say bad things about a community and then not backing it up with at least a subjective detailed report of what happened.

And I find it rude to make sudden demands of strangers. Maybe we can agree to disagree.

Not a demand, just a request. Your "no thanks," is ok with me.

You wouldn't be helping the company (perhaps indirectly), but rather the community. That's my primary concern.

Languages seem to find a "killer app" much like most technologies and then tend to be used primarily for that purpose. Could Go do all of those things? Sure, with enough time, resources, and libraries, it could. But Google has a problem now (in scale) that Go excels at and can provide value now, so they use it for that.

That said, I would guess that most of Google's code is still C++, Python, and Java.

There's two senses of "scale:" large software, or software running with large data sets. The article uses the first notion: "at scale, for large programs with large numbers of dependencies, with large teams of programmers working on them."

So Go was designed for large software systems, and maybe it's really good at those things. Or maybe not, because nobody's written one yet. The article says so: "We don't have enough experience yet, especially with big programs." So Go is unproven in this way.

Speculatively, my guess is that it won't be able to "at scale" its current state. For example, Go errors out with unused variables, imports, or indeed for all warnings. Imagine trying to make a piece of software like WebKit or LLVM compile on all of the platforms it supports, with all of the compilers they support, without introducing a single warning (or extraneous header or unused variable) on any of them. It would be a maintenance nightmare. You need some flexibility - demanding perfect hygiene for every cell on an NxM matrix of supported platforms is infeasible.

In the other sense of scale - large data sets - Go apparently works well enough to be involved in YouTube. That's cool and is a credit to it.

You're saying that if Go had the same design flaws as C/C++, then it wouldn't be possible to write LLVM in it.

But Go doesn't most of the design flaws you mentioned. For example, there are no multiple Go compilers wildly diverging in what they understand. That's unique to C++. In Go, like in Java or C#, a compiler either implements the whole spec or it cannot be called a compiler.

Go also doesn't have the portability problems that have accumulated in C/C++ over decades.

Go doesn't have macros (which enable the mess that C/C++ code finds itself in).

Go doesn't have manual memory management, pointer arithmetic, array access is always bounds checked etc. - it's radically safer language than C/C++.

I also fail to see the logic connection between unused variables or unused imports and any of that.

Or how fixing the error caused by unused variable is a "maintenance nightmare". Count the number if #ifdef statements in boost and then let's have a discussion about what is and isn't a maintenance nightmare.

> For example, Go errors out with unused variables, imports, or indeed for all warnings.

Go doesn't have warnings. The Go compiler errors out on compile errors. Unused variables and imports are two things that people typically assume should be warnings, and are surprised to find them as errors.

So I don't think your fears are well-founded here. Go is a much stricter and clearly defined language than C. There are far fewer edge cases and ambiguities. The spec is much easier to implement, and indeed there are two complete compiler implementations that agree with each other and the spec.

That WebKit or any other large C project could produce no warnings is, of course, hard to imagine. C compilers emit warnings like... well, I can't think of a clever simile. But the point is, it's totally normal for C programs to emit tons of warnings. But ANY Go program (valid or not!) can never produce any warnings. Ever.