The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect.

Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it.

I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.

Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps.

C is too low level for those kinds of things, and Go too high level.

Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters.

E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.

And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.

Outside of the lack of bindings to proper UI frameworks, I couldn't say why you shouldn't write e.g. Word in a higher level language than C++. You might have to be careful with memory usage in some components, maybe even write those in native code, but for the vast majority of interactions something higher level should work, shouldn't it?

After all you can implement something akin to Word in JS + HTML (Google Docs).

Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.

Casting every list element to "interface{}" is not generic.

Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.

If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.

When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway.

It is the way it has been done in C for decades too.

What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming.

Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classes defined irrespective of the concrete data types used upon instantiation". That reads like "templates" to me.

Templates are generic, but so is, e.g. the type inference used in functional languages.

There are certainly lots of abstractions you can express in Golang.

From all accounts it will never ever get generics.

> and C++ is better for performance.

As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.

But the big question is, is it really that much slower?

And the fact that it is a GC language means it is a much simpler language than C++.

Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment.

You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects.

Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.

So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not.

Whether they think relying completely on the heap is a "small" cost or not.

Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.

Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.

Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.

And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.

Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.

I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.

A language that doesn't affect the way you think about programming, is not worth knowing.

Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.

Wouldn't learning a new language expand your toolset? Not replace it.

And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.

And you can't use go outside of the "PC" (that is, embedded systems).

Why not? It runs on Arm.

But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)

Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.