Comment by ithkuil | Hacker News Reader

Comment by ithkuil | Hacker News Reader

Parent Full thread

That doesn't answer the question though.

Go channels (and slices and maps) are special built-in types that are already "generic", i.e. they have type parameters: "make(chan Foo, 10)".

Is there some property of the built-in buffered channel contract that makes it hard to implement as efficiently as this ring buffer?

Anyway. The ability to implement user-defined data structures with the full power of the language (e.g. building your own 'chan T') allows one to choose some different guarantees and target different use cases

If it is indeed faster, my gut is that it wasn't generic, it was "generic" hah. Ie runtime reflection was used instead of true compile-time generics. Runtime reflection has a cost, and is (was!) one the strongest arguments against Go. All powerful "generic" code you'd write in Go heavily relied on reflection over interfaces that caused memory behavior commonly associated with worse performance.

Compile-time generics can often perform similar behavior but with a far better memory layout resulting in better performance.

Purely speculation though about `chan`, i have no clue.

Have a look at the runtime, on my system the code is in

   /usr/local/go/src/runtime/chan.go

There are some reflection calls in there, together with mutex lock/unlock and calls to 'typedmemmove' which seems to involve the use of memory barriers (mbarrier.go in the same directory).

Reply on news.ycombinator.com