Le C++ vs. Go

http://commandcenter.blogspot.ca/2012/06/less-is-exponentially-more.html

But the C++0x talk got me thinking again.  One thing that really bothered me—and I think Ken and Robert as well—was the new C++ memory model with atomic types. It just felt wrong to put such a microscopically-defined set of details into an already over-burdened type system. It also seemed short-sighted, since it's likely that hardware will change significantly in the next decade and it would be unwise to couple the language too tightly to today's hardware.

We returned to our offices after the talk. I started another compilation, turned my chair around to face Robert, and started asking pointed questions. Before the compilation was done, we'd roped Ken in and had decided to do something. We did not want to be writing in C++ forever, and we—me especially—wanted to have concurrency at my fingertips when writing Google code. We also wanted to address the problem of "programming in the large" head on, about which more later.

>>15
You don't even need that for any userland applications (if you're programming a kernel, Go really is the wrong tool).

If you REALLY need pointer arithmetic (protip: you don't), you have the unsafe.Pointer type, into which you can cast any type and cast it into any type.

Otherwise, these things are perfectly acceptable for most, if not all, userland applications. The lack of pointer arithmetic only makes it harder for you to screw stuff up without sacrificing any real usefulness, while GC removes one of the most dreaded problem of C, memory leaks, at a negligible performance cost.

All in all, wanting pointer arithmetic in userland programs is misguided and ``no GC'' is premature optimization in most cases.