[iheartmemcache]

Originally it was positioned as a 'systems' programming language (i.e. the C/C++/Rust/D domain) - the community quickly re-oriented itself to more of a Python replacement for the obvious benefits it offered.

Network/server projects is exactly what I see it being handy at. You get a fast compile-time language that can do things with your logs/analytic aggregate information in an ad-hoc fashion (really fast compile times and better-than-dynamic-languages-performance), which previously would have costed a lot of time in learning the whole Pig/Hadoop/etc ecosystem or a lot of money in any of the BusinessObjects-esque tooling.

Gofmt eliminated styling wars, go doc integration is handy, great 'batteries included' tools out of the box for, typing safety that's comfortable for people who are used to dynamically typed languages to move over without too much hassle[1]. Out of the box code-coverage tooling, good DVCS support, import support for Github is clever (though arguably not the best idea re: security, handy nonetheless since you avoid having YetAnotherPackageManagerWar (pip vs setuptools in Python). The lack of generics (interface{} is such a hack, just like void * in C) is problematic for some, unfortunately.

I don't use Go much because I'm a self-admitted typed language elitist but it is definitely a well-designed language[2].

[1] I don't think the average Pythoner really wants to think about co/contravariance unlike in Scala, or Haskell98's type system + the bevy of lang extensions that fall in and out of fashion. [2] Though there's tons of room for improvement-- my hope is that Go moves at the Meijers-C# pace which seems to be a perfect trade-off between adding features not too slowly (i.e. the first 15 years of Java/JVM -- only recently has this changed) but not too quickly either (stability is certainly important, no one wants to see their old code break because a new keyword was added which you previously used as a variable; or far worse, subtle semantic changes in pre-existing constructs).

[microtonal]

Though there's tons of room for improvement-- my hope is that Go moves at the Meijers-C# pace which seems to be a perfect trade-off between adding features not too slowly

I wouldn't bet on it, Go's designers consider the language more or less done:

https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...

(Make sure you continue until the anti-climax.)

[Animats]

Go was created to do what Google does - server side software run in huge data centers. C++ was too bug-prone, and Python was too slow. Go has the right feature set for that job. Google then provided good libraries for most of the things you'd want to do on a server. It lets mid-level programmers do competent work without much trouble.

It's not a great choice for operating system development, real time work, client side code, graphics, games, supercomputing, or "frameworks". That's OK. For the job it was designed to do, the features are there.

[unscaled]

The main problem with Go is that it was originally pushed by its developers as the perfect language for these applications, and it's still actively pushed as a systems language in some circles.

The Go language FAQ still states that no "No major systems language has emerged in over a decade". Besides ignoring the system languages which did emerge, this sentence misleads the reader into thinking that Go is a systems language.

And I'm not talking about garbage collection here, which is often cited as why Go can't be a systems language. GC makes it hard to write some of the applications of a systems programming language, such as OS kernels and games, but it's not mutually exclusive, and OSes have been written in GC languages before (Lisp Machines, Singularity with Sing#). It's the entire approach: Go offers its own scheduler (which is really great, but if you need to use something else, you're in for some pain) and no support of writing dynamically linked modules. It makes go very inconvenient for most common system applications, unfortunately. Essentially, it's manages to be less high level than C++ (it has fewer robust typing and features), while not being low level enough to beat C++ in the same time (very inflexible binary target, GC-only, no inline assembly).

[Animats]

Go, the language, is better than Go, the PR. The early promotional materials claimed way too much. Some of those documents are still out there, especially "Effective Go". But the language, although overhyped, came out OK.

Go is really the successor to Java and COBOL. It's what you write your business logic in. We needed that. Java had accumulated too much excess baggage.