Как можно на go написать бд, которая не будет поддерживать многопоточность?
Ты не так понял :-)
George
George
Там все равно вывод сериализованный
George
И скорее всего "многопоточность" != "Кооперативность"
George
И я говорил за то, что библиотека есть, но напрямую пячить ею данные запущенного прома - плохая идея
Bogdan (SirEdvin)
А, это да
Oleksandr
и еще вопросик. а есть что-то, кроме прома, что использует промовский тсдб?
Bogdan (SirEdvin)
Но это не многопоточность, это скорее устойчивость к фигне. Просто с точки зрения модели go, емнип, практически всегда количество потоков как минимум по количеству ядер, а значит нужно всегда следить локами или страдать костылями
George
Bogdan (SirEdvin)
Имхо, ограничивать программы на go одним ядром - это очень жесткий костыль. В таком случае уж сразу лучше писать на python или rust
Евгений
Как можно на go написать бд, которая не будет поддерживать многопоточность?
Легко, вообще many-writes это очень дорогая операция, ща бы её поддерживать во встраиваемой db.
Каналы позволяют просто фигануть в отдельную горутину всю запись, а потом туда посылать то, что нужно писать.
Евгений
https://godoc.org/github.com/prometheus/tsdb#Appender
Operations on the Appender interface are not goroutine-safe.
Евгений
Тут вполне типичная схема many reads+one write
Александр
Мне как-то страшновато на прод с латестом, предпочитаю конкретную версию в композе прописывать
Vladimir
Мне как-то страшновато на прод с латестом, предпочитаю конкретную версию в композе прописывать
И это верно) А то рано или поздно, с этим можно словить неприятные проблемы...
George
Ну, если у вас четкий регламент билда и билды не каждые пять минут, то почему бы не катить лейтест
Vladimir
Georgiy
Oleksandr
Беда ж при откате не с приложением, а с данными и/или структурами данных
George
А откатываться как?
На старую версию приклада - ну, так через передеплой или можно сохранить айдишник старого образа.
Vladimir
На старую версию приклада - ну, так через передеплой или можно сохранить айдишник старого образа.
Ну это же не удобно? При использование, точной версии достаточно нажать ретрай и нужная версия уедет на прод.
Ну и если есть с 3 десятка сервисов, то всегда есть вероятность, что не доехал новый образ и потом сложно понять, что реально крутится в проде и почему бага не воспроизводится в песочнице...
Хотя, я возможно, чего-то не понимаю
Oleksandr
Ну это же не удобно? При использование, точной версии достаточно нажать ретрай и нужная версия уедет на прод.
Ну и если есть с 3 десятка сервисов, то всегда есть вероятность, что не доехал новый образ и потом сложно понять, что реально крутится в проде и почему бага не воспроизводится в песочнице...
Хотя, я возможно, чего-то не понимаю
хорошая тема. мегахорошая. это раньше называлось депенденси хэлл
Oleksandr
с приходом микросервисов эта тема должна умереть. но в теории
George
Она вышла на новый уровень
George
Уровень взаимодействия микросервисов между собой
George
Ну это же не удобно? При использование, точной версии достаточно нажать ретрай и нужная версия уедет на прод.
Ну и если есть с 3 десятка сервисов, то всегда есть вероятность, что не доехал новый образ и потом сложно понять, что реально крутится в проде и почему бага не воспроизводится в песочнице...
Хотя, я возможно, чего-то не понимаю
В случае с докером - помимо тега есть image id, так что проблемы нет. Если артефакт какой-либо другой - ну, да: лучше уже не на лейтест, а точную версию указывать
Gleb
Уровень взаимодействия микросервисов между собой
тут важно понимать - это правда микросервисы или "распределенный монолит", если все правильно архитектурно сделано то боли не будет
Bogdan (SirEdvin)
Все равно будет, когда будете выпускать новую версию api. То есть, конечно, можно делать все "постепенно", но не всегда есть возможность
George
В случае изменения апи нужно передеплоивать "микросервис-клиент" (потребляющий апи) и "микросервис-сервер" (предоставляющий апи)
Anonymous
@graz0001 будет жить. Поприветствуем!
Anonymous
@Prorezk1 будет жить. Поприветствуем!
J
libpng-dev поставил
Azer
Сюда можно зафигачить опрос для удовлетворения праздного интереса?
Я могу, конечно, подозревать, что половина местных работает в FAANG и пишет как минимум модули ядра на работе каждый день, но я заметил, что за последние два года мне потребовалось написать ровно 0(ноль) строчек кода на императивных языках программирования(Go, Python, Ruby): всё за меня уже давным давно сделано в опенсорсе, мне остаётся это только взять и применить. Не то что бы меня это сильно парило, просто интересно, насколько это воспроизводимо вне моего локального пузыря, в котором довольно неплохо платят за yaml-погромирование.
George
пили
Bogdan (SirEdvin)
Azer
George
и стать главным по ямл программированию?
George
проголосовал йоу
Aleksey
Bogdan (SirEdvin)
У нас все настолько грустно, что я еще и код продуктовый пишу :)
Vlad
Senior YAML developer
Евгений
Aleksey
тулинг
Aleksey
если ты не в рх работаешь
Aleksey
баш чмошат питон нет
Евгений
Я вижу такое деление естественным:
- пишу только конфиги
- пишу ещё и скрипты
- пописываю тулинг
- залезаю в продуктовый код
dk
Скромно умолчали про Perl
dk
Разве перл хуже питона?
Евгений
define хуже
Aleksey
трололо моде он
Евгений
Язык это набор качеств, не существует объективного способа линейный порядок на языках ввести
Евгений
Питон можно ненавидеть уже только за from lib import *
Всё что угодно можно за что-то любить, а можно за что-то ненавидеть
Aleksey
Ну вот можно так за все скать: "делай хорошо"
нет. просто используй бестпрактисы языка. проверяй линтеремми и выполняй их рекомендации.
Aleksey
для перла мне линтеры не известны так же как и ide. но наверное потому что мне пофиг и я не интересовался
Евгений
нет. просто используй бестпрактисы языка. проверяй линтеремми и выполняй их рекомендации.
А есть линтер для перла? Ну кроме wc -l?
Aleksey
сейчас @dkguest нам расскажет
🏳️ Phil
что такое "линтер" кстати?
Aleksey
что такое "линтер" кстати?
херня которая проводит сообщение у вас код плохо отформатирован
dk
интересный. если выводит не 0 значит всё плохо ?
В яндексе такой есть, сурьезно (хотя нет, я вру, там такая метрика для кода на баше есть)