16gb - мало

Здравствуйте, подскажите как лучше парсить json в структуру, если неизвестен формат json?

то есть есть строка, в которой 100% будет json-объект, но поля этого json-объекта неизвестны

понятно, спасибо

ну и такие конструкции тоже помочь должны: switch value.(type) { case int: case string: case default: }

ну и такие конструкции тоже помочь должны: switch value.(type) { case int: case string: case default: }

Ток там int не будет

а что там? int32? 64?

float64 кончено же

float64 кончено же

Данил, загляни сюда - сэкономишь стипендию @golanglibrary

А кроме введения в го что-нибудь будет?

Я готов 😂

Я готов 😂

вытащу мамонта) 6 соединений в среде(одной среде) с высоким packet loss дадут больше оверхеда в бизнес логике приложения чем какой-то пользы) TCP о многом позаботится сам, сети сейчас достаточно избыточны в плане пропускной способности, достаточно стабильны. А где нет ни первого, ни второго, общее latency и так просядет что не будет никакой интерактивности =) ИМХО, похоже на попытку забить лом, когда гвоздь чуть кривоват)

https://github.com/techtrain-go/race

Ты сдал проект?

С чего вы решили что позаботится?

иди работай! :)

хм, со спецификации? не?)

play.golang так долго хранит записи. Открыл код от 9 июля 2016-го

Ну как бы тут разговор про поведение congestion control.

Это мне и не понятно. congestion относится к методам по реализации низкоуровневого транспорта. Какое отношение мультиконнекты имеют к состоянию среды вокруг которого flow только tcp? Если у тебя 20% packet less /s, то значит ~ то же самое будет и на других соединениях той же среды. Причем общее latency за счет того, что будет видимая "параллельность" запросов просядет не сильно, уж тем более если пайплайн и нужна очередность. Деградация 1 запроса будет приводить к деградации всего пулла(говорили же про round robin еще какой-то), т.е будет rtt деградировать(не только latency сети). То, о чем говорили, имеет смысл использовать когда есть вообще запасные каналы связи, аля другие среды. В остальном латание дыр среды в контексте этой самой среды и какого-то мультиконтекста для мнимого улучшения rtt выглядит крайне не рабочим

А теперь возьми 0.01% потерь и много мелких параллельно идущих запросов. И вариант либо клиент получит сразу несколько респонсов позже либо один.

Речь не про это, ты предлогаешь дробить отправку данных по мультиконнектам? Сколько у тебя будет "много мелких"?) Как определить как мне перекрывать dos'илкой высокий latency канала?) Про оверхед в бизнес логике вообе молчу

Это мне и не понятно. congestion относится к методам по реализации низкоуровневого транспорта. Какое отношение мультиконнекты имеют к состоянию среды вокруг которого flow только tcp? Если у тебя 20% packet less /s, то значит ~ то же самое будет и на других соединениях той же среды. Причем общее latency за счет того, что будет видимая "параллельность" запросов просядет не сильно, уж тем более если пайплайн и нужна очередность. Деградация 1 запроса будет приводить к деградации всего пулла(говорили же про round robin еще какой-то), т.е будет rtt деградировать(не только latency сети). То, о чем говорили, имеет смысл использовать когда есть вообще запасные каналы связи, аля другие среды. В остальном латание дыр среды в контексте этой самой среды и какого-то мультиконтекста для мнимого улучшения rtt выглядит крайне не рабочим

Зачем слака, если есть телега?

Что это за loop на 64 строке? https://github.com/adonovan/gopl.io/blob/master/ch8/du4/main.go В книге ничего про это не сказано, в туре тоже не увидел

Именованный фор

Суббота же 😛

Slack удобнее в некотором плане (можно пометить сообщения как "прочитаю/отвечу потом" + sub-каналы на дискуссии вокруг определённых сообщений)

Именованный фор

На работе слак имеет смысл, а в чатиках с рандомами хз, смылса маловато.

А как гуглить-то? Ничего не понял