Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.

I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level.

It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.

Due to my engineering background, I would always sacrifice performance for less risk and more reliability.

I've also spent 20 years writing C and C++ so I know how horrible it is.

The anything-but-the-OS-niche? I thought we had plenty of languages for that.

It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.

You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?

Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that?

When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)

Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.

We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far.

You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?

I don't ignore performance. There are many ways to achieve performance. I've worked on embedded systems (military, medical sector) and occasionally need direct hardware access which is where I use C/C++ and that is primarily to manipulate a device and hand off a suitable abstraction to a higher level language (with a garbage collector).

When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)

That is all down to determinism. Determinism can be achieved in various simple ways. If you understand the language, you can write code that pre-allocates and reuses memory in critical sections therefore invoking no garbage collection penalty. Isolating critical sections from each other is still a problem in C/C++ if you consider the threading model that they use.

Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.

I'm not a fan of all "those 20 JVM-based languages" - I find them tedious and ugly. I'm the most critical person on the planet when it comes to this sort of thing. Go pretty much hits the mark.

I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism i.e:

   func CriticalFunc() {
       defer runtime.ResumeGC()
       runtime.PauseGC()
       // critical section
   }

I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.

These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.

I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.

There's more than one way to skin a cat on this one.

And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.

  for (Object o: collection) {
  }

If you are interested, android team at had several talks at Google I/O (not just 2012) about optimizing memory usage.

AdaCore provides high quality compilers and tools (GPLed) under http://libre.adacore.com/

Interested fellas might start with reading this article: http://www.adacore.com/adaanswers/gems/gem-30/

EDIT: oops, that should be an answer to eckyptang... anyway, check out Ada. :)

Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java.

If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.

In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed).

And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code.

One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable.

ArrayList<String> x = Lists.newArrayList("b", "c", "d", "a"); Collections.sort(x); System.out.println(x);

Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ?

As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend.