это не оптимизации. Если мы просто хотим инициализировать пустой срез, то var s []T даст нам его без аллокаций. Никакой добавленной стоимости.

Есть случаи, когда предварительное выделение просто зряшное прописывание нулей

а что мешает реализовать REQ-REP поверх WS?!

ну если мы сделаем s := ... то же горя не будет - как удобнее будет по месту

а нафига нам пустой срез

возможна аллокация пустого массива. Вопрос, зачем?

не поверите, но такие ситуации бывают

Коллега, не тупите :)

ну рано или поздно он либо будет не пустым, либо вообще не нужен

При всём уважении.. WS это просто full-duplex труба.. заливаешь в одну сторону - выливается на другой.

Я уже писал и multiplexed REQ-REP поверх WS, и просто REQ-REP

И небольшое преимущество в том, что connection аутентифицируется 1 раз при создании, а дальше у нас сессия ассоциируется с сокетом, и валидировать её не надо.

HTTP-же stateless, следственно в каждом из запросов нам обязательно нужно валидировать сессию либо криптографически (JWT) либо с помощью look-up таблицы (session ID).

однако у WS из-за statefulness’а проблемы возникают на уровне load balancing’а

тут кстати не понятно, по идеи мы скопировали слайс но указатель на внутренний массив - без изменений

но s снаружи не заполняется

все, прояснил наконец-то для себя вопрос про nil-значения
правильный ответ - nil-слайс инициализируется автоматически при первом его изменении и не вызывает паники в циклах по нему
как-то "zero value is ready to use" вводит в заблуждение, что память таки выделяется, раз оно живое и шевелится при тыканье палочкой
https://play.golang.org/p/FspmC6jT13n

Потому что слайс это структура, и она скопировалась через аргумент

слайс это структура с указателем

скопировалась... но у ней есть указатель на массив который тоже скопировался

пересоздание внутреннего указателя там явно нет

append в данном случае инициализирует слайс

Аппенд создал вам новый слайс, но этот слайс остался в функции