I've never used go professionally and most of my spare time is split between C++ and Scheme at the moment, but when I did go spelunking with Go, I found it a breeze to write complicated functionality in it - it felt like C++, but easier and more initially powerful.

I still feel that C++ is generally a better choice, but if I only had a short time to write something in, I would definitely go for Go.

I'm curious, if you can get things done more quickly in Go, why do you feel C++ is generally a better choice? Performance?

For me, I just don't see enough benefits of Go over C++. I already know how to use C++ in a way that avoids or mitigates the problems Go solves. With C++11 support starting to take off Go's advantages are even smaller.

On the other hand, if I didn't know C++ and I was looking for a native compiled language to learn, I'd probably choose Go over C++.

Depending on what you're doing, the libraries make a giant difference. Look over Go's standard library packages and then imagine what a pain in the ass it would be to find and manage all the separate C/C++ libs it would take to replicate all that functionality (or to write it yourself).

Performance, I also feel more in control, it's hard to describe the feeling, it's just as though Go is providing an abstracted interface to the hardware, where as C++ provides raw, unfiltered but potentially dangerous access.

Perhaps it's just my personal experience though.

That kind of fits Rob Pike's explanation for why Go isn't more popular with C++ programmers (although he gave it a negative spin).

In a neutral way, it's like: if you spent all that effort mastering this language to get such fine-grained control, why would you give that up again? And really, I understand: why would you give that up? Especially if you know how to use C++ in a fairly painless way.

Do you have a link to that? I would be interested to read it.

I also couldn't agree more, but normally, people retort with the Hammer and Screwdriver argument.

> Performance, I also feel more in control, it's hard to describe the feeling, it's just as though Go is providing an abstracted interface to the hardware, where as C++ provides raw, unfiltered but potentially dangerous access.

Funny I though C++ did exactly the same thing. Where are the L1, L2 and L3 caches references, multiple opcode execution pipelines, processor instructions ?

> where as C++ provides raw, unfiltered but potentially dangerous access.

Wouldn't that be assembly? Last time I heard Stroustrup, he was all raving about abstractions, not raw unfiltered access.

Generic code?