[ChuckMcM]

As one of the folks who was on the Java team when it was released to the public, I can tell you the response was very different than the response to Go's announcement.

Having been at Google (but not associated with Go in any way while there) when Go was announced my question then, as now, was "What was the problem again?"

The basis of that question is that languages that have been successful often, but not always, have a strong correlation with solving a painful problem.

Java solved a number of problems; the problem of connecting across architectures (I thought of it as the 'system libraries' problem), the C++ is too complicated problem (which would be the too complex;didn't learn (tc;dl) problem), and the interactive content from an untrusted source problem (which, in all fairness was a problem it self created when being able to run in a browser).

The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem (which is huge, but why ignore millions of man hours in HDLs which also solve this problem but with the caveat that you have to be able to infer hardware from the compiled code)

So unless there is something that is much easier to do in Go that you both need to do, and is so much better that doing it in your current language is too painful, it will join the ranks of languages like Lisp, APL, Modula-n, and Eiffel which all have things to recommend them but nothing to compel them into wide spread adoption and use that we associate with a 'popular' language.

"An important thing to note is that, while Go is a great general purpose language, we're building it to make systems development easier. That's what we're using it for at Google, and also how it's being used at other companies like Canonical and Atlassian."

Historical reference see the design, development, and use of the best language you've never used Mesa [1].

[1] http://en.wikipedia.org/wiki/Mesa_%28programming_language%29

[zmmmmm]

My interest in Go stems from its potential to replace C as a systems programming language. Basically, it seems like everything that has been tried for improving upon C has failed. However this is not because C doesn't have problems, rather it's because every replacement has been trying to achieve other things at the same time and has introduced complexities that made things worse.

So I think it's interesting to have a language that is finally being built with the primary purpose of being better than C at systems programming. My main issue however is the lack of support for Windows. One of the main points of a system language and the reason C dominates is that with enough hacks you can make it portable to anywhere. I can understand the Go folks probably don't have much interest in or use for Windows (or resources to support a port) but honestly, in my mind that's just incompatible with the stated goal of being a "systems programming language".

[enneff]

There is a small group of dedicated programmers working on the Windows port, and it works. Not 100% parity with the other Operating Systems, but it passes most tests: http://godashboard.appspot.com/ (see the rightmost column)

[enneff]

"The only problem that I have ever heard as being at least in the sights of Go was the 'building parallel applications' problem"

That's only a small part of it. It's also designed to be less confusing than C++, and more flexible and faster than Java. As a result, it's actually a very different kind of language. Feels like a scripting language, but you get static typing and the performance of a compiled language.

Lots of smart programmers are finding good use for Go, so your comments seem like unnecessary and misplaced negativity to me.

[jbarham]

> Feels like a scripting language, but you get static typing and the performance of a compiled language.

Exactly. I'm a longtime enthusiastic Python programmer and reluctant C++ programmer, and for me Go is the first language that could realistically replace both Python and C++ for my programming.

For me the killer features of Go are:

- Go code is almost as compact as Python but--especially for numeric code--much, much faster.

- You never have to wait for the compiler! Everything I've written compiles and links in a fraction of a second.

- Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code.

Note too that, apart from the C runtime and low-level OS interfacing stuff, the entire Go standard library is written in Go itself. Contrast this w/ "scripting"/dynamic languages like Python or Ruby where much of the standard library has to be written in C for performance.

(FWIW I have published some open source Go code on Github at http://github.com/jbarham and the beginnings of an AWS library at http://code.google.com/p/goaws/.)

[runT1ME]

Go isn't the only language that matches those requirements though. I took a long hard look at Go for very similar reasons and ended up deciding on Scala.

It feels like a scripting language, incredible performance, extremely compact code when you need it to be, actors.

>Easy CSP-style concurrency: goodbye races and deadlocks w/ threaded code.

I actually disagree with this, CSP style, actors, message passing, you still have potential race conditions and deadlocks. What you gain is a nice separation between what is shared and what isn't. Just don't think Go's concurrency is the many-core silver bullet anymore than locks or Tx Memory is...

[crawshaw]

Java solved a number of problems, but introduced some of its own.

The work I do in C++ I could do in Java, but the extra memory and compute overhead would cost us on the order of another engineer. Go interests me because it might let me escape C++ without the cost of Java. (Go may still prove too expensive, my experiments aren't done yet.)

Also: Go developers have the Python ethos of short names and simple interfaces. Take a look at the Go standard library[1]. I may get the safety of Java and the productivity of Python in one go.

[1] http://golang.org/pkg/

[dkarl]

The fact that it was created by a big rich company makes all the difference. Seriously. Companies commit themselves to development projects in hideous proprietary languages like ABAP without a second thought, but a well-regarded language with multiple high-quality implementations can be a difficult sell if it comes without a ™ and a corporate logo.

[bryanwb]

Go does solve some painful problems for certain communities, esp. the linux desktop folks. Java hasn't caught on writing linux desktop apps, probably because of memory requirements and there are mixed feelings about Mono. Python is just too darn slow for such apps. I imagine this is why Canonical is using Go. Admittedly this isn't a huge space.