> As Go is a GC based language I would expect it will always be slower than non GC languages like c/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.
>But the big question is, is it really that much slower?
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.
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++.