острие бритвы читал? огонь вообще

может, у тебя перевод был так себе?

Острие бритвы не читал

бремя стратей у него унылое, луна и грош слогом тащит, его на английском 100% надо читать, а вот всякие вуали и бритвы — одни из лучших книг вообще

Спасибо, почитаю на досуге.

Ребята, можете посоветовать литературу помимо вышеуказанных?

http://4gophers.ru/books#.WK2-I4iGO00

подскажите вот что. У меня есть массив на 1000 элементов, можно без мьютекса заполнить массив через горутины? Если чтение массива будет не скоро

Заполняй канал и в обычной рутине вытаскивай

Не?

Ребят пока только погружаюсь в Golang и тут у меня есть вопрос, как мне парсить если приходит разный json Строка 47

пробовать сначала одно, потом другое

пробовать сначала одно, потом другое

так топорно?

так топорно?

да никто так не делает - всегда приходит что-то одно. если не ложится в концепцию делается а-ля контейнер типа Packet и туда кладется Player и Message и что-то из этого будет nil

подскажите вот что. У меня есть массив на 1000 элементов, можно без мьютекса заполнить массив через горутины? Если чтение массива будет не скоро

Типа func one(a int, c chan int) { c <- a } c := make(chan int) go one(1, c) go one(2, c) for i:= 0; i < 2; i++ { arr[i] = <-c }

Еще есть raw message

да никто так не делает - всегда приходит что-то одно. если не ложится в концепцию делается а-ля контейнер типа Packet и туда кладется Player и Message и что-то из этого будет nil

> да никто так не делает - всегда приходит что-то одно. Ну вот тут и вопрос как понять что пришло, первое или второе

Ну вообще не отправлять разные схемы по одному коннекту например

Или отправлять и помечать что за схема

Или отправлять и помечать что за схема

как

вот это интересно

Типа шлешь первым символом число и потом из raw message его читаешь, отбрасываешь и потом конвертишь

Но лучше по одному коннекту одну схему гоняй

Можно схему тип, объект, а в структуру долбишь тип и кучу объектов

Но лучше по одному коннекту одну схему гоняй

и если у меня 5 разных сообщений что 5 коннектов? 1 новый игрок подключился 2 ему приходит массив игроков 3 пакет в котором координаты новые

и т.п.

type Message struct { Type string, Person, Car }

Типа шлешь первым символом число и потом из raw message его читаешь, отбрасываешь и потом конвертишь

ну не, это через чур уже. в заголовки HTTP загнать свой кастомный и там написать что приезжает сейчас, потом те варианты что я предложил - впихнуть в одну структуру эти две это первый и по эндпоинтам разнести это второе а-ля http://—/message и http://---/person

Ну по эндпоинтам я и предлагаю как лучшее решение

Но он одним сокетом хочет

ааа там веб-сокет. ну тогда в одну структуру все варианты сгоняет а-ля Packet и потом проверяет все варианты на nil - тот что не nil тот и пришел

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

Я б тип слал

Чтоб не проверять, а свич

да я тоже тип всегда слал в таких случаях, последний раз в protobuf

Мало ли, просто хочется без тела что-то кинуть, все Нил будут

Но да, про заголовки забыл

Тоже идея хорошая

Но не для сокета)

(могу ошибаться правда, но в них же нет заголовков)

для вебсокета не хорошая идея, это если без него - тогда применимо, делал один раз так, но не для разных сущностей, а для разных форматов сериализации - тип сереализации передавал и принимал в заголовке http

ааа там веб-сокет. ну тогда в одну структуру все варианты сгоняет а-ля Packet и потом проверяет все варианты на nil - тот что не nil тот и пришел

а не будет ли это оверхедом?

а не будет ли это оверхедом?

будет конечно. как минимум две фигурные скобки и запятая - 3 символа, целых 6 байт в UTF-16 или 3 байта в UTF-8

ну пробелы мож там еще -)

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

1. распарсили тип сообщения

2. распарсили payload

никаких вариантов

и это не топорно, это так, как есть

выше описан вариант, где в два прохода ничего не нужно парсить

это который?

А не пытаешься ли ты сэкономить все теоретические оверхэды в ущерб здравому смыслу или даже реальности?

а не будет ли это оверхедом?

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

А не пытаешься ли ты сэкономить все теоретические оверхэды в ущерб здравому смыслу или даже реальности?

Возможно

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

лишних данных не будет. лишние данные это те, которые не используются, а тут они используются для определения того, что прилетело

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

В курсе про невозможность 100% КПД? Похожая ситуация

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

тогда вторым этапом пойдет создание специфической структуры из общей. все равно два этапа

лишних данных не будет. лишние данные это те, которые не используются, а тут они используются для определения того, что прилетело

я определяю по полю Type а зачем мне отсылать к примеру Message если я отправляю только Person

В курсе про невозможность 100% КПД? Похожая ситуация

ЛАдно я понял

я хочу нереального

Не

Ты отправляешь тип

слать надо всегда специфическую структуру

И мессадж

А персон будет нил

нил - это я, если кто не в курсе :)

А персон будет нил

а точн, она не будет инициализированна

нил - это я, если кто не в курсе :)

ТЕБЯ НЕТ?!

короче

протоколы вроде json rpc 2.0 парсят в два прохода.

самосборный протокол можно собрать и на общей структуре (пока разные по типу поля не пересекутся по именам)

но, умоляю, не надо передавать общую структуру в обработчики

делайте специфическую копированием, и передавайте ее

мы тут сделали ошибку нечаяно, передавали общую

выпиливали с матами - некоторые компайл-тайм проверки перестали работать, и это нас огорчило

про оверхед

это как спор про динамическую и строгую типизацию

вы помните, что там у вас ssl на входе?

он ест достаточно проца, чтобы ваш оверхед не был особо заметен

Я поддерживаю не слать невнятности

протоколы вроде json rpc 2.0 парсят в два прохода.

я вообще хотел комбинировать для больших данных протобаф

джсон для разовых

Огребешь потом по полной

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

джсон для разовых

и еще msgpack для чего-нибудь возьмите. будет радость пидораса

Хочешь слать странный джсон, принимай нодой, ей типизируй и пробрасывай в го, лол

и еще msgpack для чего-нибудь возьмите. будет радость пидораса

чем плох формат сериализации? отличный формат

Хочешь слать странный джсон, принимай нодой, ей типизируй и пробрасывай в го, лол

не забрасывайте камнями, я просто хочу попробоват ьпереписать вот это https://github.com/Edisoni/uWebsocketServer

любой один - хорош

там на UWS

больше одного по одному соединению - горите в аду

больше одного по одному соединению - горите в аду

тут такой вопрос никто не поднимал

+100500

Ну у вас то не бесит этот json unmarshall ?

Но да, у нас формат один, схемы разные

msgpack очень хороший формат, очень подходит для стримов - быстрый и никаких лишних аллокаций если на стримах юзать