It's official: Go sucks, ABSTRACT BULLSHITE FTW

http://yager.io/programming/go.html

Sage for offtopic, but -

>>99

Like that time he said you don't need to care about endianness because only compiler writers like himself need to know about it.

If you look at the example he gave, he was actually right. The point being made was that you oughtn't care what the endianness of a C type is, e.g.

uint8_t *lebuf;
uint32_t val;

val = 0
| (lebuf[0] << 0)
| (lebuf[1] << 8)
| (lebuf[2] << 16)
| (lebuf[3] << 24);

works no matter what the representation of uint32_t happens to be. You only need to care about what the representation of the bytestream is, which is fine. It may indeed generate faster code on some systems if you just do

val = *(uint32_t *) lebuf;

but this isn't universally true or portable in any way.

Show me a modern codec that doesn't care about endianness.

For multimedia, I'd hope that any endianess issues would be handled in the format demux code (which is probably IO bound anyway) rather than in the compressor / decompressor where speed is actually important.