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

так лучше, но кроскомпиляцию это не вернет

Я на всякий случай еще раз попрошу прощения если кого задел. Ни в коем случае не хотел никого обидеть. Просто так слово за слово перешли на то как надо писать код, а оттуда как надо коммитить. Эти принципы я формулировал для своей команды. Свой код я пишу придерживаясь своих принципов (да и то не всегда). Но это не значит что я готов за них драться. Пишите как вам нравится) Ребейзите наздоровье, покрывайте все интерфейсами. Я не против ни в коем случае. Всем спасибо за отзывы, было увлекательно. Часть я учел, спасибо. Если что по базе - пишите в личку, я пока выйду чтоб не провоцировать никого.

да, аналог sqlite-а на чистом Го был бы очень гут

ну еще nosql не одними b-tree бэкендами живы, бывает что sqlite не подходит по перфомансу для задачи

https://github.com/rqlite/rqlite не ? я правда не трогал

а почему именно bolt?

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

Sqlite монстр?

какой же?

как сконвертить канал в read/write only?

ch := make(chan Type) ch_readonly := ???(ch)

https://github.com/cznic/ql

cannot use loggerCC (type chan chan Event) as type chan<- chan<- Event in assignment

ок. для него есть jdbс драйвер?

Канал каналов вообще так себе идея

норм идея. У меня есть логгеры, каждый со своим каналом. И есть менеджер логгеров, который этими каналами управляет

мне кажется у sqlite довольно узкая ниша которую можно описать как "хочется sql но постгрес тащить не хочется"

в playground на схожий код компилятор не ругается https://play.golang.org/p/EZf9sExbHwA

норм идея. У меня есть логгеры, каждый со своим каналом. И есть менеджер логгеров, который этими каналами управляет

Звучит как broken by design

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

Здравствуйте)

Неужто и вы гошник? 😏

высказывания, не подтверждённые аргументами

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

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

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

Наверное есть генератор каналов. 😏

при создании воркера попросил у менеджера канал для него

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

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

а не похожа? С недавних пор)

Можно запустить воркеров и не закрывать их, а по каналам им работу сгружать

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

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

Ничем не обоснованное утверждение

это ТЗ такое. Мне приходит внешний вызов, для которого я запускаю воркер

Прям в ТЗ?