и им отдельный вопрос, как они читают синиорский код на джаве / скале?

и читают ли вообще

это не то, чем стоит гордиться :Р

зависть, гадкое чувство!

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

По-моему все, что не haskel, то примитивное - дискасс

и им отдельный вопрос, как они читают синиорский код на джаве / скале?

код на скале - это отдельный вопрос. код на джавке, если в команде нормальный лид и соблюдается код-конвеншн. то джуны отлично будут читать сеньорский код

а разве сеньоры по умолчанию не должны писать код, который могут отлично читать джуны? Я думал говнокод - прерогатива джунов, а у сеньоров "с великой зарплатой приходит великая ответственность", не?

а разве сеньоры по умолчанию не должны писать код, который могут отлично читать джуны? Я думал говнокод - прерогатива джунов, а у сеньоров "с великой зарплатой приходит великая ответственность", не?

не должны

а разве сеньоры по умолчанию не должны писать код, который могут отлично читать джуны? Я думал говнокод - прерогатива джунов, а у сеньоров "с великой зарплатой приходит великая ответственность", не?

все так

а джунам не тяжело читать err != nil в каждой строке ?

По-моему все, что не haskel, то примитивное - дискасс

А как же Idris

обычно через строчку же, что вы все врете?

через две, там ещё }

а разве сеньоры по умолчанию не должны писать код, который могут отлично читать джуны? Я думал говнокод - прерогатива джунов, а у сеньоров "с великой зарплатой приходит великая ответственность", не?

не всегда. иногда приходится писать "плохой код".

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

я думал мы про маня-мирок, где кто-то кому-то что-то должен :D

Господа, есть какой-то список must-know вопросов на гошного мидла?

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

Господа, есть какой-то список must-know вопросов на гошного мидла?

"1. Молитесь ли вы на Роба Пайка?"

а джунам не тяжело читать err != nil в каждой строке ?

зачем обрабатывать ошибку, если можно её игнорить ?)))

зачем обрабатывать ошибку, если можно её игнорить ?)))

eeee, _ ^^

зачем обрабатывать ошибку, если можно её игнорить ?)))

если есть эксепшены то можно

Коллеги, кто-нить NATS юзал?...

никто с картинки код читать не будет

давайте ссылку на плейграунд

я прочитал. этот код страдает какой-то херней.

+

Судя по заголовку, делает awesome.

Так ли важно, что этот код делает, по сравнению с вечным вопросом, зачем он это делает.

Если серьёзно, что именно тебе не понятно?

Если в деталях объяснять, что он делает, долго будет

Алексей Прокопчук: Добрый день ,мне просто надо создать две гоурутины и передать обеим сразу значение map через sync.mutex

через sync.mutex это мощно) у нас обычно через каналы передают

без ГМО и асбеста)

Написал 2 статьи как я делаю онлайновую игру на Go http://dorogoy.tilda.ws/gosaveindie1 http://dorogoy.tilda.ws/gosaveindie2

кстати, если уж экономить на спичках, то почему бы не FlatBuffers вместо protobuff ?

без ГМО и асбеста)

А я специально ищу продукты с ГМО и асбетом ))

Но тщетно ((

Алексей Прокопчук: Добрый день ,мне просто надо создать две гоурутины и передать обеим сразу значение map через sync.mutex

Ты что хочешь-то, sync это у нас примитивы синхронизации, mutex здесь, чтобы одновременно горутины не начали писать в вывод и не сломали вывод, тебе нужно либо статику передать, то так и возьми ее по имени переменной, если что-то получать и выводить, то гугли golang channel

кстати, если уж экономить на спичках, то почему бы не FlatBuffers вместо protobuff ?

во-первых для онлайновых игр это не экономия на спичка а так можно и флэт буффер, на тот момент когда я начал пилить флет буффера не было

кстати, если уж экономить на спичках, то почему бы не FlatBuffers вместо protobuff ?

а из мелочей есть разница в размере пакетов, флетбуфре толще

на 30% без zipa

с зипом 20

а можно мне код на плей который на скрине выше?

мне просто свербит угадал ли я вывод или нет :)

по прикидка подождет секунду, напишет "a work two goroutines" и после разлока мьютекса два раза принтом пустой мап распечатает

потом сдохнет (истек таймер в майн процессе)

да я прав - https://play.golang.org/p/PsXRLN8KmVA :)

а из мелочей есть разница в размере пакетов, флетбуфре толще

это тоже принципиально для игр О_о

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

конечно чем меньше пакет тем лучше

иначе я не заморачивался с дельта компрессией это та тема от которогой игровой опыт зависит

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

1Kb?!

However, an intermediate network along this connection supports only 1-KB packets. Every 3-KB packet sent by the client to the server will be fragmented by the intermediate network into three 1-KB packets and the server node will have to put the pieces back together before delivering the data to the application. Because this is an expensive process that can impact throughput and network performance, IP fragmentation should be avoided whenever possible.

кто что юзал для лемматизации в го?

русский язык

конечно чем меньше пакет тем лучше

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

или там каждый раз всё пересробирается при любом запросе на сервер?

ты про протобаф сейчас?

или там каждый раз всё пересробирается при любом запросе на сервер?

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

ты про протобаф сейчас?

я пытаюсь понять на что влияет +- 1 кб в репе

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

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

так пинг превращается из 40 мс в 120

что значит при пинге? пинг постоянный, во всех играх есть тик сервера, допустим 30-120 раз в секунду, по этим тикам он что-то считает и отправляет на клиент в моем случае у меня полупошаговая, я не на каждый тик отправляю на клиент сообщение. только если есть что отправлять

ERROR: S client not available

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

флэт буфер очень хорошо будет жить там где очень часто нужно отправлять очень мало информации, один string, несколько интов

клёвый ник

Где репорт на него можно кинуть?

вроде как сразу банить можно за рекламу лол

Чудо пришло в группу к нам!

флэт буфер очень хорошо будет жить там где очень часто нужно отправлять очень мало информации, один string, несколько интов

я в таких случаях использую тупо [количество байт] + [инты и стринги] + [crc32]. Чуть больше говнокода, зато безотказно

чем вам msgpack не msgpack?

я в таких случаях использую тупо [количество байт] + [инты и стринги] + [crc32]. Чуть больше говнокода, зато безотказно

фишка в том чтобы работать со своими гошными структурами

и не делать мэппинг

чем вам msgpack не msgpack?

ну это же fixme парсируемый формат а мы тут типа за срашную экномию

и что намеряли? какая получилась экономия?

товарищи подскажите. Правильно ли на go делать веб-сервер скажем под 100к запросов в секунду? Если да, то какие будут советы? Наверное, не просто http.ListenAndServe или как?

и что намеряли? какая получилась экономия?

у msgpacka немного больше размер сообщения процентов на 10 но сериализует быстрее мне schemaless совсем не нравится подход когда я меняю протокол передачи я хочу чтобы клиент и сервер одновременно показали мне где у меня ошибки

Ещё одна распределённая DB теперь над MySQL http://radondb.io/

и что намеряли? какая получилась экономия?

у меня значительная была экономия на десериализации при переходе от protobuff к flat buffers - от 2.5 с на пакет до 2 c (пачка - несколько мегабайт). В браузере, куда пачка приходит - оно ещё больше

нагрузка на проц тоже заметно меньше стала

про браузер нам не интересно на самом деле.

мне ещё как интересно, на мне фронт висит

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

Ещё одна распределённая DB теперь над MySQL http://radondb.io/

с вашего позволения, профоловлю ваш пост в чатик mysql, интересно послушать мнение людей.

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

это слабо утещает когда клиентское приложение начинает лагать при десериализации. Вообще не понятно почему только 20% улучшение, а не 90% . что там ещё влияет кроме парсинга - загадка

При работе с каналами получил такую ошибку: fatal error: all goroutines are asleep - deadlock! всего две горутины которые обмениваются между собой сообщениями как можно избежать такую ошибку?

это слабо утещает когда клиентское приложение начинает лагать при десериализации. Вообще не понятно почему только 20% улучшение, а не 90% . что там ещё влияет кроме парсинга - загадка

сколько ж там данных? вы мегабайты гоняете?

https://youtu.be/6p4JP-HBfrQ?t=773 нормальный видос нашел на эту тему

При работе с каналами получил такую ошибку: fatal error: all goroutines are asleep - deadlock! всего две горутины которые обмениваются между собой сообщениями как можно избежать такую ошибку?

код покажи

сколько ж там данных? вы мегабайты гоняете?

биржевые котировки. в этой сфере мегобайты - это мало

товарищи подскажите. Правильно ли на go делать веб-сервер скажем под 100к запросов в секунду? Если да, то какие будут советы? Наверное, не просто http.ListenAndServe или как?

https://m.habr.com/company/mailru/blog/331784/

товарищи подскажите. Правильно ли на go делать веб-сервер скажем под 100к запросов в секунду? Если да, то какие будут советы? Наверное, не просто http.ListenAndServe или как?

просто http.ListenAndServe

https://m.habr.com/company/mailru/blog/331784/

при чем тут это?

просто http.ListenAndServe

а сколько выдержит?

а возьмите да померяйте