Во нашел, если кому интересно https://dgraph.io/blog/post/introducing-ristretto-high-perf-go-cache/

Половина синтаксиса в комментариях
Сцуко, буквально сишный код надо писать в комментариях, причём официальная документация использует для этого line-комментарии, хотя в Go есть блочные
nil != nil
обработка ошибок через пары
JSON-энкодер почему-то эскейпит HTML (wtf)
стек время от времени рандомно копируется целиком в другое место
ссылка на слайс может протухнуть — нет гарантии, что она указывает всегда на один и тот же объект, даже если её никто не менял
Можно просто пойти, сделать, и разыменовать нулевой поинтер
Нет способа защитить структуру от получения некорректного значения, любой пидорас может сделать var x ExternalType и получить тип, забитый нулями. Никакого аналога PIMPL нет.
Дженериков нет даже на уровне C11
defer вместо RAII/finally — это лишь слегка лучше чем C-style goto free;, потому что теперь тебе нужно думать в каждом месте, что закрывать
Вся простота Go идёт нахер, когда ты пытаешься действительно заставить семантику горутин работать — сам Роб Пайк обосрался на презентации, когда попытался привести простой пример паттерна. В реальности этот простой пример содержит неочевидный на первый взгляд баг, потому что по chan <- mess нет способа узнать, блокирующая это операция или нет.

У Go есть некоторые прикольные вещи, вроде горутин, или iota, но это невероятно всратый язык

Дженерики скоро будут

Их ещё нет, а они уже говно. Я читал пропозал.
То есть да, они заткнут часть существующей дыры, но они юзабельны только с тайплистами, они плохо взаимодействуют с интерфейсами на поинтерах и в целом имеют много очевидных проблем.
Это уже обсуждали здесь.

Ну ок. Я сильно не вдавался в подробности. Просто знаю, что сделают скоро

Там прикол в том, что для многих операций тебе нужно указывать, условно, не T: Into<i32>, а T: i8 + i16 + i32 + u8 + u16

Плюс эджкейс с поинтерами: если у тебя есть один интерфейс реализованный на T, а другой на *T, что в го происходит постоянно, ты никак не можешь потребовать оба.

Что это значит?

Вместо констрейнтов ты просто буквально указываешь список типов, которые ты принимаешь.

Мощно

Вот пример из пропозала:

package constraints

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
  type int, int8, int16, int32, int64,
    uint, uint8, uint16, uint32, uint64, uintptr,
    float32, float64,
    string
}

А, да, и ещё у них теперь будет проблема с тем, что они не могут поменять интерфейс std до 2.0, поэтому им придётся писать вторую generic-std рядом.

package constraints

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
  type int, int8, int16, int32, int64,
    uint, uint8, uint16, uint32, uint64, uintptr,
    float32, float64,
    string
}

С запашком

Людям нравится

Но главная проблема это поинтеры

type A interface {
    foo()
}

type B interface {
    bar()
}

type S struct { }

func (S self) foo() { }
func (*S self) bar() { }

func takesFoobar[T A](x T) {
    x.foo() // Ok
    (&x).bar() // Not ok
}

Способа запросить T: A, *T: B просто не существует.

Как они переобулись в номинатив)

Ладно, сьеду с темы, для меня недавно было открытием что делая предположения о распределении входных данных мы можем получить алгоритмическую сложность лучше поиска основанного на сравнениях за меньше чем log n

Они и были в номинативе. Дженерики работают через номинативные интерфейсы.