Хандлер принимает данные ивента

Можно вообще без корутин

Без корутин и каналов в мультитридинг и асинк?

Ну хочется асинк

Запускаете хендлеры в корутинах

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

Примерно раз в три месяца тут спрашивают что пишут на Го. Ответ всегда одинаковый - прокси сервера.

Примерно раз в три месяца тут спрашивают что пишут на Го. Ответ всегда одинаковый - прокси сервера.

Нет же. Ответ всегда - микросервисы.

Нет же. Ответ всегда - микросервисы.

нет. у меня но есть, а микросервисов нет

нет. у меня но есть, а микросервисов нет

Я не спорю, я им вообще логи парсю. Но когда-то то спрашивает, обычно отвечают, что микросервисы.

Я не спорю, я им вообще логи парсю. Но когда-то то спрашивает, обычно отвечают, что микросервисы.

микросервисы лочень специфичная тема то

Согласен:)

Ну и это как с кластерами. Все о них говорят, но в реалии

Ну и это как с кластерами. Все о них говорят, но в реалии

В реалии у меня эластик в кластере) Но это для соседнего чатика тема

А вот коллеги, есть ли какая-то либа для распространения событий между разными горутинами? Хочется иметь типа диспетчер каналов с разными событиями. Иметь возможность взять канал у диспетчера и в него закинуть. А в нескольких горутинах подписаться на этот канал и получать одно и тоже. Типа, диспетчер pubsub на fan-in/fan-out. Бывает такое или самому писать?

Эта штука называется nsq

Эта штука называется nsq

Так, за nsq спасибо. Но это про распределенные системы. Я хочу просто внутри приложения это сделать. Т.е. по мне так это пишется за пару часов, но лень же:)

https://golanglibs.com/search?q=pubsub

Слушайте, вопросец есть по встраивание структур в структуры

Как лучше встраивать повторяющиеся элементы в структуры JSON?

списком

в json есть такой, между [ и ] токенами перечисляешь повторяющиеся структуры через запятую

Я вижу 4 варианта, но распишу два: type SampleText struct { Test `json:"user_name" } type Test struct { string } или type SampleText struct { Test `json:"user_name" } type Test struct { Test string }

Найдите 5 отличий?)

оба не конпелируются?

а, нашёл

Найдите 5 отличий?)

Ну, в обеих случаях мне придётся таскать поезд var.Test.string или var.Test.Test

А я ожидаю от встраивания просто var.Test

extends ищешь? :)

Структур у меня много и получается что половина содержимого требуется расписывать до третьего уровня, а половину - до второго. Хотя я могу не встраивать повторящиеся части вовсе, а продублировать их как любой другой объект. Но тогда при изменении объекта придётся все структуры её содержащие поправлять, что не очень

extends ищешь? :)

Типа того

оба не конпелируются?

Компилируются

Я вижу 4 варианта, но распишу два: type SampleText struct { Test `json:"user_name" } type Test struct { string } или type SampleText struct { Test `json:"user_name" } type Test struct { Test string }

Почему 4 варианта - просто возьмите первые два и перенесите `json:"user_name"` во встраиваемую структуру.

И, как бэ, какой вариант лучше?

Или есть альтернативные способы встраивания?

И я не совсем понимаю разницу между: type SampleText struct { Test Test } и type SampleText struct { Test }

Так, за nsq спасибо. Но это про распределенные системы. Я хочу просто внутри приложения это сделать. Т.е. по мне так это пишется за пару часов, но лень же:)

Задача специфическая. Я думаю поэтому общего решения и нет

Задача специфическая. Я думаю поэтому общего решения и нет

Ну, счёт специфичности я бы поспорил, но т.к. мало что остается на долго в рамках одного процесса, то видимо nsq

Ну, счёт специфичности я бы поспорил, но т.к. мало что остается на долго в рамках одного процесса, то видимо nsq

Специфика не в постановке задачи (даже я понял чего ты хочешь), а специфика в обработке что ли.

Go умеет в понимание int как bool?

Не

Чтобы 1 = true, а 0 = false Или только через if?

а как у тебя кейс прости, где не if?

Нигде. Просто спрашиваю, вдруг я зря if леплю

Нигде. Просто спрашиваю, вдруг я зря if леплю

кейс приведи

Есть структура: verifiedEmailResponse struct { Request Request `json:"request"` User struct { Activated int `json:"user_activated,omitempty,string"` } `json:"user"` } Есть функция, которая и так работает с этим куском: ... var obj verifiedEmailResponse if err := json.NewDecoder(bytes.NewReader(resp)).Decode(&obj); err != nil { return false, err } if obj.User.Activated == 1 { return true, nil } return false, nil

Чтобы 1 = true, а 0 = false Или только через if?

Только if . И это действительно круто. Да, иногда хочется тернарного оператора. Но и без него можно жить.

Только if . И это действительно круто. Да, иногда хочется тернарного оператора. Но и без него можно жить.

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

Ничего против не имею лишние три строки накатать

Есть структура: verifiedEmailResponse struct { Request Request `json:"request"` User struct { Activated int `json:"user_activated,omitempty,string"` } `json:"user"` } Есть функция, которая и так работает с этим куском: ... var obj verifiedEmailResponse if err := json.NewDecoder(bytes.NewReader(resp)).Decode(&obj); err != nil { return false, err } if obj.User.Activated == 1 { return true, nil } return false, nil

А. Понял. Нет не зря.

Просто если есть способ проще, который я просто не уточнил о его существовании, то зачем лепить больше? :D

Просто если есть способ проще, который я просто не уточнил о его существовании, то зачем лепить больше? :D

map[int]bool{ 0: false, 1: true}

map[int]bool{ 0: false, 1: true}

Тоже вариант

1 будет тру, остальное false вроде.

map[int]bool{ 0: false, 1: true}

Это типа проще? Это шутка такая?

Это типа проще? Это шутка такая?

Может и не проще, но как альтернативный вариант пойдёт

return obj.User.Activated == 1, nil

так не пробовали?

Это типа проще? Это шутка такая?

Так один раз создал, а потом используешь. Если у тебя в проекте регулярно надо. Так-то конечно if

return obj.User.Activated == 1, nil

О

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

Так один раз создал, а потом используешь. Если у тебя в проекте регулярно надо. Так-то конечно if

Только взять из мапы операция чутка тяжелее простого if. И если тебе это регулярно надо, ты начинаешь подогревать воздух на пустом месте

Такое встречается раза 2-3 всего, думаю можно пренебречь картами

Только взять из мапы операция чутка тяжелее простого if. И если тебе это регулярно надо, ты начинаешь подогревать воздух на пустом месте

If: 2000000000 0.39 ns/op Map: 300000000 4.56 ns/op Ну, на порядок разница:)

Это было ожидаемо

If: 2000000000 0.39 ns/op Map: 300000000 4.56 ns/op Ну, на порядок разница:)

и это еще хорошо, что на один

Ну вот если бы там было не только 0 и 1 мапить, а много интов, тысячи их, то мапа была б пошустрее :)

Заранее извиняюсь за нубский вопрос, но есть ли способ опимизировать подобную конструкцию? if param1, ok := job.GetParamString("param1");ok { if param2, ok := job.GetParamString("param2");ok { if param3, ok := job.GetParamString("param3");ok { // Using params1...3 } } }

ERROR: S client not available

Ну вот если бы там было не только 0 и 1 мапить, а много интов, тысячи их, то мапа была б пошустрее :)

т.е. ты хочешь реализовать odd и even через мапу?

Ну вот если бы там было не только 0 и 1 мапить, а много интов, тысячи их, то мапа была б пошустрее :)

не обязательно

В общем, потесть. Всё, что помещается на экран в виде select (по целочисленным ключам) всегда будет быстрее в виде select, чем в виде map.

т.е. ты хочешь реализовать odd и even через мапу?

Нет, я ж не говорю, что там чётные обязательно будут false, а нечетные true.

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

Ну вот если бы там было не только 0 и 1 мапить, а много интов, тысячи их, то мапа была б пошустрее :)

Ну это другая задача

Может быть ты даже прав для 100 кейсов (именно по-этому я и написал "всё что помещается на экран")

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

кодоген

Заранее извиняюсь за нубский вопрос, но есть ли способ опимизировать подобную конструкцию? if param1, ok := job.GetParamString("param1");ok { if param2, ok := job.GetParamString("param2");ok { if param3, ok := job.GetParamString("param3");ok { // Using params1...3 } } }

А в чем проблема?

Да ? я практически ни когда не делал кодеген...

Да ? я практически ни когда не делал кодеген...

а пишешь на языке, где почти всё -- кодоген

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

А в чем проблема?

в один if собрать позволяет Го ?

а пишешь на языке, где почти всё -- кодоген

Ты имеешь в виду библиотеки?

Но я сам не реализовывал codegen ?

в один if собрать позволяет Го ?

А зачем?

Ты имеешь в виду библиотеки?

Я имею ввиду язык

А зачем?

нет я в общем, конструкцию типа (...) and (..) там не применить?

Может быть ты даже прав для 100 кейсов (именно по-этому я и написал "всё что помещается на экран")

Для 16 switch такой же быстрый, как if, мапа становится в 3 раза медленнее. А дальше мне лень печатать))

нет я в общем, конструкцию типа (...) and (..) там не применить?

Применить. Т.е. можно взять все три параметра в ok[1-3] и потом просто через && проверить

Применить. Т.е. можно взять все три параметра в ok[1-3] и потом просто через && проверить

если вывести функции присвоения перед if? или по другому

если вывести функции присвоения перед if? или по другому

Да попробуй и так. Что нам говорит эксперимент?

Я просто расчитывал на что то подобное if a, ok1:= get(), b,ok2:= get(); ok1&&ok2 { // Using a b }

Я имею ввиду язык

Тогда я тебя не понимаю.

Можешь пояснить своё высказывание?

Можешь пояснить своё высказывание?

Огромная часть гошки - кодоген транспилятора с сей

Ты имеешь в виду runtime, который когда-то был написан на C, потом транспилен на Go? С тех пор его существенно почистили.

Ты имеешь в виду runtime, который когда-то был написан на C, потом транспилен на Go? С тех пор его существенно почистили.

Не только рантайм же

А что ещё?

Да и те же мапы не изменялись, насколько помню, совсем

В любом случае, то что оно когда-то было написано на C , это уже просто достояние истории. Сейчас оно написано на Go, и ни куда не транспилится.

И выглядит оно как написанное на Go, т.е. стиль после транспилятора поправили.