А какая альтернатива? Или просто закопали без предоставления другого инструмента?
flutter - остальное не стоит свеч
Oleg
gulaev
Nail
ASP.NET Blazor
Null
если ормка на рабочем проекте, судьбой предначертано от него потом избавляться
Работал в бигтехах, там есть ОРМ в финтехах даже.
John
Поч? Кому плохо?
Мне. Мне ормы заходят только в определенных узких ситуациях, типа форма поиска со 100500 фильтров или что-нибудь вроде GraphQL.
Но это уже моё личное субъективное мнение, которое я никому не навязываю
Null
Ну тогда и говори не «это плохо» а «мне плохо» 🤣
Null
Держись главное
Oleg
Мне. Мне ормы заходят только в определенных узких ситуациях, типа форма поиска со 100500 фильтров или что-нибудь вроде GraphQL.
Но это уже моё личное субъективное мнение, которое я никому не навязываю
а как же миграции ? я бы не стал однозначно говорить хорошо или плохо, по моему нужно смотреть по конкертному кейсу
sergey_cyi
Мне. Мне ормы заходят только в определенных узких ситуациях, типа форма поиска со 100500 фильтров или что-нибудь вроде GraphQL.
Но это уже моё личное субъективное мнение, которое я никому не навязываю
Для динамических запросов можно юзать sql билдеры(динамические условия или вставка/обновление массива данных). Всё останое руками
sergey_cyi
Для динамических запросов можно юзать sql билдеры(динамические условия или вставка/обновление массива данных). Всё останое руками
Тут как бы понятно, что свои билдилки через fmt каждый раз писать не прикольно, но орм для этого не нужен
John
а как же миграции ? я бы не стал однозначно говорить хорошо или плохо, по моему нужно смотреть по конкертному кейсу
А что миграции? Храните схему бд в проекте в отдельных файлах на каждую итерацию изменений в схеме (см. goose). И вопросы миграций и откатов будут решены гораздо лучше. Более того, вы вынесете вопрос миграций за пределы зоны ответственности вашего приложения.
John
Для динамических запросов можно юзать sql билдеры(динамические условия или вставка/обновление массива данных). Всё останое руками
Можно. Тогда еще меньше поводов юзать ормы.
Null
Null
Да не, я согласен с тобой, пойми. Я вот Uber FX ненавижу.
Эти модули писать везде, плюс рефлексия, я вообще ей не доверяю. А там ещё ограничения на неэкспортируемые интерфейсы она накладывает, в общем, любой, кто использовал достаточное время, поймет.
Но на работе текущей используют. Просто выбранная компанией технология. И вот мой такой хот тейк в том, что чем меньше я буду бузить и упираться, тем мне же легче будет. Сам лично видел, как людей увольняли за эту «негибкость к технологиям».
MATYSHA THREAD EXPANSION
есть ощущение что как будто в го не нужен диай фрейм
Согласен. В cloud в целом как будто этого не надо
MATYSHA THREAD EXPANSION
есть ощущение что как будто в го не нужен диай фрейм
Я думаю, что DI фреймворки имеет смысл использовать, когда вы разрабатываете приложение на чём-то, что стоит выше языка(тоже какой-нибудь фреймворк). Пример - игра. У вас есть фреймворк в виде движка и т.к. игровой движок это огромная система сама по себе - имеет смысл не писать сложные алгоритмы поиска подсистем, а прокидывать их через DI
Василий
Я думаю, что DI фреймворки имеет смысл использовать, когда вы разрабатываете приложение на чём-то, что стоит выше языка(тоже какой-нибудь фреймворк). Пример - игра. У вас есть фреймворк в виде движка и т.к. игровой движок это огромная система сама по себе - имеет смысл не писать сложные алгоритмы поиска подсистем, а прокидывать их через DI
А что мешает явно передавать в конструктор?
Stepan
Null
Какой di фрейм по вашему лучше?
Лучше самописный контейнер
Да, больше писать.
Но больше гибкость применения и просто как-то чище и понятне выглядит на мой взгляд.
Null
есть ощущение что как будто в го не нужен диай фрейм
Только чтобы слой application не писать (по сути di контейнер это он и есть, ну почти)
И чтобы main.go не засирался.
Василий
Можно в место di который на рефлексии работает генераторы кода использовать. И ручной работы нет. И без рефлексии.
Null
Не, ну di кажется что нужен где прям сильный упор на чистую архитектуру.
А чистая архитектура, ну хотя бы на 80% нужна там, где много кода и важен порядок. Например, финтех. Люди меняются в команде, кластерах, и кажется, что хотелось бы примерно один и тот же кодстайл иметь и чтобы новый Вася приходя в команду быстро разбирался и начинал комиттить такой же чистый и правильный код, а не разгребал легаси конюшни.
Null
Можно в место di который на рефлексии работает генераторы кода использовать. И ручной работы нет. И без рефлексии.
А посоветуй такой пример? Или самому писать надо генератор кода?
Ilya
вкусовщина все это
x1gluk1x
А посоветуй такой пример? Или самому писать надо генератор кода?
Скорее всего имелся ввиду Wire, на который забил гугл
Pavel
А посоветуй такой пример? Или самому писать надо генератор кода?
могу обратное показать)
if i, ok := initer.(base.Initer); ok {
a.log.Infof(ctx, "Call function %T.Init()", initer)
if err := i.Init(); err != nil {
return fmt.Errorf("call %T.Init() got: %w", initer, err)
}
}
func (a *App) addEntityCloser(name string, entity interface{}) {
if bc, ok := entity.(io.Closer); ok {
a.addNamedCloser(name, bc)
func setDB(a *App) error {
return a.everyEntityNamed("setDB", func(i interface{}) error {
if h, ok := i.(base.Databaser); ok {
if a.DataBase == nil {
return checkToUse(h, "database")
}
h.SetDB(a.DataBase)
}
return nil
})
}
Pavel
могу обратное показать)
if i, ok := initer.(base.Initer); ok {
a.log.Infof(ctx, "Call function %T.Init()", initer)
if err := i.Init(); err != nil {
return fmt.Errorf("call %T.Init() got: %w", initer, err)
}
}
func (a *App) addEntityCloser(name string, entity interface{}) {
if bc, ok := entity.(io.Closer); ok {
a.addNamedCloser(name, bc)
func setDB(a *App) error {
return a.everyEntityNamed("setDB", func(i interface{}) error {
if h, ok := i.(base.Databaser); ok {
if a.DataBase == nil {
return checkToUse(h, "database")
}
h.SetDB(a.DataBase)
}
return nil
})
}
switch x := f.(type) {
case func(*App) error:
return x(a)
case func(context.Context, *App) error:
return x(ctx, a)
case ActionFunc:
return x(ctx, a)
}
вот после таких неявных вызовов веришь в магию
антон
Не, ну di кажется что нужен где прям сильный упор на чистую архитектуру.
А чистая архитектура, ну хотя бы на 80% нужна там, где много кода и важен порядок. Например, финтех. Люди меняются в команде, кластерах, и кажется, что хотелось бы примерно один и тот же кодстайл иметь и чтобы новый Вася приходя в команду быстро разбирался и начинал комиттить такой же чистый и правильный код, а не разгребал легаси конюшни.
Мне кажется, контейнеры зависимостей абсолютно ортогональны чистой архитектуре. И явно противоречат философии го.
Null
Null
Мне нравится вот это
func (c *Container) GetPostgres() *pgxpool.Pool {
return get(&c.dbPool, func() *pgxpool.Pool {
dbPool := mustInit(func() (*pgxpool.Pool, error) {
return postgres.NewPostgres(c.ctx, c.cfg)
})
c.addCloseFn(func(ctx context.Context) error {
dbPool.Close()
return nil
})
return dbPool
})
}
func mustInit[T any](initFunc func() (T, error)) T {
obj, err := initFunc()
if err != nil {
panic(err)
}
return obj
}
func get[T comparable](obj *T, builder func() T) T {
if *obj != *new(T) {
return *obj
}
*obj = builder()
return *obj
}
И тогда вся логика main.go превращается в
c := di.NewContainer(ctx)
defer c.Close(ctx)
c.GetLogger().InfoCtx(ctx, "Running application...")
if err = c.Run(ctx); err != nil {
c.GetLogger().ErrorCtx(ctx, err, "Run command failed")
return failExitCode
}
Michael
это наверное сарказм
Null
Потому что явное лучше неявного
Тут же вообще в другом дело, контейнеры передают указатели на явные экземпляры структур, а разница только в том, где это делать. Никто не обязывает использовать рефлексию или сторонние пакеты, так что мне кажется, ты не понял суть спора и суть di
антон
А, вона чо. Но всё же это оверинжениринг по мне. Может даже дело не столько в усложнении, так то идея красивая, просто то ли синтаксис под это не очень заточен то ли у меня глаз не набит, приходится код долго разбирать мысленно.
Null
John
Какой di фрейм по вашему лучше?
Да никакой! Ну вот вообще нет никакой проблемы написать сервис провайдер и у тебя нормальный код везде без лишних зависимостей, ограничений и подкапотной магии
Null
Null
Максим
>умение писать запросы руками
>опыт работы с ОРМкой
каво?
"пишем основные запросы в ORM, сложные или дебаг/разбор руками", и нет противоерий
Максим
есть ощущение что как будто в го не нужен диай фрейм
если большое приложение, то может так статься, что 20 разрабам может надоесть носиться с конструкторами и сложные выкуртасы для декораторов делать и прочие штуки
Evgeny
если большое приложение, то может так статься, что 20 разрабам может надоесть носиться с конструкторами и сложные выкуртасы для декораторов делать и прочие штуки
если у тебя на го большое приложение и его поддерживают 20 разрабов то скорее всего что то делается не так=)
Максим
если у тебя на го большое приложение и его поддерживают 20 разрабов то скорее всего что то делается не так=)
да что вы говорите, а как делать "так"?
Максим
если у тебя на го большое приложение и его поддерживают 20 разрабов то скорее всего что то делается не так=)
я выйду сейчас за контекст обсуждения, но Кубернетис или Докер поддерживаются более чем 20 людьми 🙂 и оно одно каждое из них
руководители и архитекторы этих проектов делают что-то не так?
Oleg
Да не, я согласен с тобой, пойми. Я вот Uber FX ненавижу.
Эти модули писать везде, плюс рефлексия, я вообще ей не доверяю. А там ещё ограничения на неэкспортируемые интерфейсы она накладывает, в общем, любой, кто использовал достаточное время, поймет.
Но на работе текущей используют. Просто выбранная компанией технология. И вот мой такой хот тейк в том, что чем меньше я буду бузить и упираться, тем мне же легче будет. Сам лично видел, как людей увольняли за эту «негибкость к технологиям».
честно говоря искренне считаю что правильно негибких увольняют
я такие демарши и цирки видел что полностью поддерживаю
Null
честно говоря искренне считаю что правильно негибких увольняют
я такие демарши и цирки видел что полностью поддерживаю
Согласен. У меня на одном из проектов никак в 2к24 не могли отказаться от питона в пользу го. Дико низкий тайм ту маркет, лютое количество ошибок в проде и мерзкое количество кода, но люди тянули эту лямку до последнего, лишь бы чет новое не пробовать. Здоровья им и всех благ, как говорится.
Антон
Согласен. У меня на одном из проектов никак в 2к24 не могли отказаться от питона в пользу го. Дико низкий тайм ту маркет, лютое количество ошибок в проде и мерзкое количество кода, но люди тянули эту лямку до последнего, лишь бы чет новое не пробовать. Здоровья им и всех благ, как говорится.
технологии зачастую это выбор не проекта а компании или кластера, т.ч. + перейти с языка на язык при большой кодовой базе неимоверно тяжело, это годы работы, смены команды вплоть до техлида, потере времени с не факт что лучшим результатом, затраты на которые надо еще суметь объяснить бизнесу
⛪️Поп Гапон⛪️
Согласен. У меня на одном из проектов никак в 2к24 не могли отказаться от питона в пользу го. Дико низкий тайм ту маркет, лютое количество ошибок в проде и мерзкое количество кода, но люди тянули эту лямку до последнего, лишь бы чет новое не пробовать. Здоровья им и всех благ, как говорится.
А зачем отказываться? Скорее всего на го так же написали, но зато ГОШЕЧКА, ну и писал бы чел какой нибудь пол года минимум и булькал бы бизнесу что код сложный, непонятный, нужно время, а ну и потом бы еще пол года тестировали/запускали
Vitaliy
За счёт чего переезд с питона на го в монолите уменьшит Т2М?
Serge
За счёт чего переезд с питона на го в монолите уменьшит Т2М?
За счёт отладки. Меньше по трэйсам скакать, 😂 если обсервабилити, вообще, реализована на проекте в работающем виде. Если не реализована - то тем более.
Oleg
За счёт чего переезд с питона на го в монолите уменьшит Т2М?
Доказательств нет:) Зато доказательств обратного полно:)
Serge
За счёт чего переезд с питона на го в монолите уменьшит Т2М?
А если серьёзно - у меня за крайние месяца за 2-3 было такое количество удивительных ошибок в том, как работал Python, особенно с async - что, прям, я на Питон сейчас вообще о-о-очень с пристрастием смотрю. И где-то, даже, с боязнью. Откручивающиеся от своих event loops функции, пропадающие контексты, нелепые футуры, непонятно откуда берущиеся... Жесть, короче. И это при том, что код писали даже не сеньёры, а лиды с очень большим опытом и высокой квалификацией.
Oleg
Oleg
А если серьёзно - у меня за крайние месяца за 2-3 было такое количество удивительных ошибок в том, как работал Python, особенно с async - что, прям, я на Питон сейчас вообще о-о-очень с пристрастием смотрю. И где-то, даже, с боязнью. Откручивающиеся от своих event loops функции, пропадающие контексты, нелепые футуры, непонятно откуда берущиеся... Жесть, короче. И это при том, что код писали даже не сеньёры, а лиды с очень большим опытом и высокой квалификацией.
Представь как больно было бы если бы они плохо на го написали... а ты пришёл в проект и... они не хотят переписывать...
Serge
Такое ощущение, что Питон с годами становится похож на какого-то снеговика, которого лепять из чего попало, куда попало ему там какие-то морковки и ветки вставляют и ведро одевают тоже фиг поймёшь на какое место. 😂
Vitaliy
А если серьёзно - у меня за крайние месяца за 2-3 было такое количество удивительных ошибок в том, как работал Python, особенно с async - что, прям, я на Питон сейчас вообще о-о-очень с пристрастием смотрю. И где-то, даже, с боязнью. Откручивающиеся от своих event loops функции, пропадающие контексты, нелепые футуры, непонятно откуда берущиеся... Жесть, короче. И это при том, что код писали даже не сеньёры, а лиды с очень большим опытом и высокой квалификацией.
Ну залезть в асинхронщину на питоне... Это уже категория 18+
Oleg
Ну залезть в асинхронщину на питоне... Это уже категория 18+
Для молодых?:) А тем у кого 30+ куда залезать?:)
Oleg
Я тут месяц на js пишу... отдыхаю так сказать от go да и подтягиваю свои скилы:)
Vitaliy
Такое ощущение, что Питон с годами становится похож на какого-то снеговика, которого лепять из чего попало, куда попало ему там какие-то морковки и ветки вставляют и ведро одевают тоже фиг поймёшь на какое место. 😂
Синхронные фичи красивые. Паттерн матчинг, дженерик билтин структуры. Красота
Serge
Представь как больно было бы если бы они плохо на го написали... а ты пришёл в проект и... они не хотят переписывать...
Да я понимаю. Но с go, хотя бы, как ops, отладил бы это всё на уровне языка. Ну, нашёл бы наверняка, где там что отваливается (и, да, я не считаю go простым языком; ни в коем случае! go - язык непростой, он - хитрый и нужно кучу всего знать и код писать аккуратно). Но такого у меня, чтобы у go что-то отваливалось в разных местах, с непонятной диагностикой - такого ни разу не припоминаю, если честно. Бывали сложные случаи, да, но хоть как-то, постепенно, окапываешься до проблемного места. А у Питона так работает... непоймёшь, что: то ли вирт.машина сама по себе, то ли либы, кривые как бумеранг (pytest, pydantic, sqlalchemy) - неясно.
Так что, go может жать хотя бы какой-то предсказуемости, как мне кажется. 😳
Oleg
Да я понимаю. Но с go, хотя бы, как ops, отладил бы это всё на уровне языка. Ну, нашёл бы наверняка, где там что отваливается (и, да, я не считаю go простым языком; ни в коем случае! go - язык непростой, он - хитрый и нужно кучу всего знать и код писать аккуратно). Но такого у меня, чтобы у go что-то отваливалось в разных местах, с непонятной диагностикой - такого ни разу не припоминаю, если честно. Бывали сложные случаи, да, но хоть как-то, постепенно, окапываешься до проблемного места. А у Питона так работает... непоймёшь, что: то ли вирт.машина сама по себе, то ли либы, кривые как бумеранг (pytest, pydantic, sqlalchemy) - неясно.
Так что, go может жать хотя бы какой-то предсказуемости, как мне кажется. 😳
Распределённый монолит на гошечке с тонной кода и очередями и не до конца понятной логикой самого алгоритма - запроста отваливаться что-то где-то будет... а ну да и без документации с тестами...
Vitaliy
Распределённый монолит на гошечке с тонной кода и очередями и не до конца понятной логикой самого алгоритма - запроста отваливаться что-то где-то будет... а ну да и без документации с тестами...
Ща на гошку перепишем
@ (Шариков из Собачьего Сердца)
Багов меньше будет