я пару месяцев назад поднимал хттп3, правда nginx брал не из хаба готовый, а компилил с добавлением поддержки. в целом все завелось без особых сложностей, если не считать поиск докерфайла на гитхабе готового.
Это кстати большой недостаток го, так как ошибку в случайной горутине нельзя отловить и отправить, например в сентри. В простых веб-сервисах это решается милдварями/библиотеками, которые оборачивают каждую горутину. Но в более сложных, автоматических вариантов как в питоне, к примеру (добавил пару строчек и забыл), я не нашел.
Деплоя с конфигом явно не хватало. А как миграции происходят. Например, я запускаю инстанс в докере и хочу добавить индекс. Просто меняю конфиг и дергаю какую-то ручку? Или все же миграции нужно запускать руками в виде скриптов?
Соглашусь с предыдущими комментаторами. Нужно обязательно написать про slog. Он решает основные проблемы старого логгера. А так из сторонних zerolog мне лично больше зашел
в пхп вообще почти все смотрится как прибывшее из ада. я покодил на нем пару лет и забыл как страшный сон именно из-за тяжелочитемых конструкций, особенно в фреймворках
но вообще все сложнее - есть тяжелые костыльные орм, типа горма, а есть бойлер, или реформ (если брать го). которые избавляют от написания повторной логики (и части опечаток в запросах) и синхронизации структур с базой, добавляют комплит. в обоих есть билдеры запросов.
в джанге же орм наоброт является ведущей, что тоже избавляет от повторности и очень помогает следить за базой. при этом более 90 процентов запросов в джанге выглядят очень просто. остальные 5 процентов можно и вручную написать.
В целом верно - для каждой задачи можно найти более подходящий язык. Но (если задача не очень простая) он не будет идеальным и придется делать что-то нестандартное.
Python удобен с его кучей батареек (одна только админка django чего стоит), но на нем всегда есть соблазн уйти в оверинжиниринг, когда выходит что-то околоджавное - 10 наследований + миксины. Но если нужно сделать асинхронный код, который легко читать и поддерживать, то go показывает себя с лучшей стороны.
Идеального языка нет (могу сказать, как писавший минимум на десятке), мир не двухполярный. Поэтому у каждого языка есть варианты, как обойти ограничения. У питона есть threadpool и asyncio, которые могут позволить сделать быстрый парсер (но оба решения не без недостатков). У го есть рефлект, который позволяет удобно разбирать json. При этом так же есть вариант парсить и без рефлекта, когда нужна ультра-производительность. Вопрос в том, что ультра-производительность нужна обычно в других местах кода, а разобрать и собрать json, это вторичная операция.
это лечится L2 чисто под ордербук. И ты в итоге оперируешь им, а он оперирует в основной сети. Тоже не очень просто, но зато в этом L2 можно прописать время жизни удаленных ордеров
есть еще вариант от команды в рф - форк angie - там хттп3 из коробки, но конфиг чуть не совместим из-за названия nginx в директивах)
я пару месяцев назад поднимал хттп3, правда nginx брал не из хаба готовый, а компилил с добавлением поддержки. в целом все завелось без особых сложностей, если не считать поиск докерфайла на гитхабе готового.
У nginx кстати есть свой бесплатный проверятор, правда он по другому работает - nginx amplify
Это кстати большой недостаток го, так как ошибку в случайной горутине нельзя отловить и отправить, например в сентри. В простых веб-сервисах это решается милдварями/библиотеками, которые оборачивают каждую горутину. Но в более сложных, автоматических вариантов как в питоне, к примеру (добавил пару строчек и забыл), я не нашел.
Деплоя с конфигом явно не хватало. А как миграции происходят. Например, я запускаю инстанс в докере и хочу добавить индекс. Просто меняю конфиг и дергаю какую-то ручку? Или все же миграции нужно запускать руками в виде скриптов?
Соглашусь с предыдущими комментаторами. Нужно обязательно написать про slog. Он решает основные проблемы старого логгера. А так из сторонних zerolog мне лично больше зашел
в пхп вообще почти все смотрится как прибывшее из ада. я покодил на нем пару лет и забыл как страшный сон именно из-за тяжелочитемых конструкций, особенно в фреймворках
выглядит как будто чатгпт скомпилировал)
но вообще все сложнее - есть тяжелые костыльные орм, типа горма, а есть бойлер, или реформ (если брать го). которые избавляют от написания повторной логики (и части опечаток в запросах) и синхронизации структур с базой, добавляют комплит. в обоих есть билдеры запросов.
в джанге же орм наоброт является ведущей, что тоже избавляет от повторности и очень помогает следить за базой. при этом более 90 процентов запросов в джанге выглядят очень просто. остальные 5 процентов можно и вручную написать.
Если знаешь один язык, книги уже не нужны. С нуля определенной аудитории понимать через книги проще
В целом верно - для каждой задачи можно найти более подходящий язык. Но (если задача не очень простая) он не будет идеальным и придется делать что-то нестандартное.
Python удобен с его кучей батареек (одна только админка django чего стоит), но на нем всегда есть соблазн уйти в оверинжиниринг, когда выходит что-то околоджавное - 10 наследований + миксины. Но если нужно сделать асинхронный код, который легко читать и поддерживать, то go показывает себя с лучшей стороны.
Идеального языка нет (могу сказать, как писавший минимум на десятке), мир не двухполярный. Поэтому у каждого языка есть варианты, как обойти ограничения. У питона есть threadpool и asyncio, которые могут позволить сделать быстрый парсер (но оба решения не без недостатков). У го есть рефлект, который позволяет удобно разбирать json. При этом так же есть вариант парсить и без рефлекта, когда нужна ультра-производительность. Вопрос в том, что ультра-производительность нужна обычно в других местах кода, а разобрать и собрать json, это вторичная операция.
это лечится L2 чисто под ордербук. И ты в итоге оперируешь им, а он оперирует в основной сети. Тоже не очень просто, но зато в этом L2 можно прописать время жизни удаленных ордеров