Не надо так, каждый раз больно когда вижу эти обёртки

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

чего-же тут не так? :)

На текущий момент самый правильный путь кмк - смириться и надеяться что когда-нибудь у нас появится что-то типа Result из rust :)

енамы эмулируются на типизованных константах

Кстати, есть у кого идеи как различать после анмаршала json в Go отсутствие поля и поля со значением nil?

может есть у кого эта книга? https://www.ozon.ru/context/detail/id/1927500/

может есть у кого эта книга? https://www.ozon.ru/context/detail/id/1927500/

Да Я не могу использовать Pub/Sub, т.к. насколько понял история Pub’ов не сохраняется, а значит часть информации пропадет, если сервис, являющийся подписчиком, упадет

я что-то сылшал неплохое про https://github.com/adjust/rmq, и да, проблему Pub/Sub опишите

я что-то сылшал неплохое про https://github.com/adjust/rmq, и да, проблему Pub/Sub опишите

Про Pub/Sub Я открыл две консоли с redis-cli В одной наопубликовал несколько записей, в другой подписался после этого Никаких оповещений из канала не получил При включенной подписке - новые оповещения, как и ожидается, видны Из увиденного сделал вывод, что Pub/Sub работает в реальном времени и нигде не хранит историю Может это и не так, но кодом пока что лениво проверять

мб запись просто в один ключ идёт? хотя по логике нужно в разные, это же типа очередь. Не должно быть такой связи по логике. Если сообщения публикуются в очередь, то их может хоть 100500 там накопиться, сколько RAM позволит, а когда подписчик(и) подключи(а)тся к работе, они эту очередь и обработают

Это все-таки не очередь Склоняюсь к мнению товарища выше

это деталь реализации, имхо

ну или покажите мне где чётко прописано, что Pub/Sub не может быть реализовано очередью, мб я неграмотный

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

если перевод хороший - однозначно надо

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

пабсаб хорош но это не очередь, а скорее паттерн обсервер но с распределенными подписчиками

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

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

хорошо, а мне торренты религия не позволяет)

В роскомнадзоре работаешь?)

Всем привет Пишу систему очередей на go + redis Хочу реализовать бесконечные попытки извлечения элемента из списка и его обработку, если он не пустой Пока придумал только такой способ: https://play.golang.org/p/cfx_EUXdUO Подскажите, есть ли способы сделать лучше? Вечный цикл очень смущает 🙂

Дайте пожалуйста my.cnf разогнаной базы. (12 cores, 32 Gb RAM)

func BeginHolyWar() { remove(mysql) install(postgresql) }

хорошо, а мне торренты религия не позволяет)

Про Pub/Sub Я открыл две консоли с redis-cli В одной наопубликовал несколько записей, в другой подписался после этого Никаких оповещений из канала не получил При включенной подписке - новые оповещения, как и ожидается, видны Из увиденного сделал вывод, что Pub/Sub работает в реальном времени и нигде не хранит историю Может это и не так, но кодом пока что лениво проверять

func BeginHolyWar() { remove(mysql) install(postgresql) }

Дайте пожалуйста my.cnf разогнаной базы. (12 cores, 32 Gb RAM)

Дайте пожалуйста my.cnf разогнаной базы. (12 cores, 32 Gb RAM)

Всем привет Пишу систему очередей на go + redis Хочу реализовать бесконечные попытки извлечения элемента из списка и его обработку, если он не пустой Пока придумал только такой способ: https://play.golang.org/p/cfx_EUXdUO Подскажите, есть ли способы сделать лучше? Вечный цикл очень смущает 🙂

https://github.com/major/MySQLTuner-perl

👍🏻 спасибо

Обещанная книженция

https://hackernoon.com/communicating-go-applications-through-redis-pub-sub-messaging-paradigm-df7317897b13

https://github.com/major/MySQLTuner-perl