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.