но это не отменяет "коммита генерации"

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

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

я-ж говорил, что кешированием можно обойти полную генерацию пройдя лишь проверку чек сум

кто и что проверять будет? генераторы этого не делают.

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

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

рано или поздно вы будете собирать проекты со скоростью С++, если даже в других языках и проектах с множеством кода, это рано или поздно становиться реальностью, проекты разрастаются. Кодо-генерация - это хорошо, когда сделано грамотно и применена "к месту". Ран-тайм "аннотации" - тоже хорошо и удобно, когда "к месту". Чтобы быстро собирать большие проекты, есть решения, в java - это билд кэши, успешно применяются в некоторых билд-тулзах (gradle). Без них - попа, скалисты "страдают", потому что там SBT тулза по умолчанию без них, а с ними сборка может "ускорятся" в 4-5 раз. Рано или поздно Go тожк к этому придет, когда код-база многократно вырастет.

рано или поздно вы будете собирать проекты со скоростью С++, если даже в других языках и проектах с множеством кода, это рано или поздно становиться реальностью, проекты разрастаются. Кодо-генерация - это хорошо, когда сделано грамотно и применена "к месту". Ран-тайм "аннотации" - тоже хорошо и удобно, когда "к месту". Чтобы быстро собирать большие проекты, есть решения, в java - это билд кэши, успешно применяются в некоторых билд-тулзах (gradle). Без них - попа, скалисты "страдают", потому что там SBT тулза по умолчанию без них, а с ними сборка может "ускорятся" в 4-5 раз. Рано или поздно Go тожк к этому придет, когда код-база многократно вырастет.

не будете. Не надо сравнивать компилятор Go и компилятор C++ Компиляторы C++ были основаны на дизайне, который учитывал ограничения железа 80-90 годов (в основном по памяти). А сейчас у нас памяти в ноуте как тогда в мега-дата-центре

Не согласен. Памяти тогда было - столько сколько было, оно соответствовало тем "маленьким" программам, которые были востребованы. Сейчас памяти больше, но стало использоваться "выведение типов" повсеместно в ЯП, контроль типов разными видами, контроль видимости и времени жизни. Не тешьте себя иллюзиями (как я думаю), что вот сейчас "много памяти", а это автоматически значит, что Go компилятор "построен по другим принципам" создания компиляторов. Эти принципы "принципиально не изменились" (имхо). И если сейчас кода относительно не много, то потом будет много и билд-тул, который будет собирать многомодульный проект из 10-ка частей - это станет реальностью, как у других ЯП.

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

тем и прекрасен процесс создания нового языка - можно сбросить тонны легаси с плеч и идти новым путём учитывая ошибки прошлого

можно учитывать не только ошибки, но и то хорошее, что уже есть. в других ЯП есть долгий путь, который они проходили ... например : сборка ручками, позже ANT, потом Maven, Gradle. Так что многомодульный билд-тул, который будет - генерить, копировать файлы обновляя ресурсы, компилить это все, собирать в более крупные модули (учитывая зависимости между модулями), деплоить на сервер, архивировать и т.д... - это реальность в других ЯП, просто "молодым и горячим" это не ведомо, до поры и времени.

не "можно" а "нужно" 😊

проблема плюсов не в хедерах, а в темплейтах, и - в меньшей степени - в препроцессоре

в любом случае сравнивать C++ компиляторы с компилём Go - не лучшая идея. Они реализуют спецификации разных эпох, в Go вредный легаси не тянут как в плюсах в виде, например, header файлов, Go принципиально должен компилиться быстрее (зависит от уровня отладки)

проблема плюсов не в хедерах, а в темплейтах, и - в меньшей степени - в препроцессоре

а хедера на современном железе проблемы не представляют

я вот тут телеграм десктоп собирал. больше часа повторная компиляция после правки одной строки

а что с темлейтами не так?

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

» думаешь о небольших сервисах, то писать можно хоть на ...... Ибо сложность единицы небольшая, тестируешь ее снаружи..... Обратная сторона - увеличивается кол-во связей, а потом растет их "сложность и взаимодействие". Сам микросервис не работает "в безвоздушном пространстве", а взаимодейтсвует с остальными компонентами... и может даже "асинхронно". Чем больше связей, тем сложнее взаимодействие - тем больше гемороя. Так что "не стоит обольщаться"

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

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

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

то и называю - барьеры между модулями. например - формализованное api для модуля. в монолите мало кто заморачивается, в микросервисах придется. количество связей то же, просто в микросервисах они документированы и зафиксированы

для бэкенда стоит переходить с пхп на джава

Ну мы делаем не прям микро. Просто такие небольшие с определенной специализацией. Переписываются многие за недели от силы. Но это на прям микро, где на каждый чих целый сервер с апи

а вы делаете/используете что-то типа: - Saga pattern - Transaction log tailing ? просто интерес...

Не обязательно API барьеры, у вас же может быт так, что "сохранение/удалени записи в/из базу" (одного микро-сервиса), вызывает автоматическую генерацию сообщения к другим "зависимым подсистемам" (мик-сер.), которые ловят его через "брокер-очередь" и обрабатывают своим образом, а может еще и порождают "свои команды/события". Тут барьеры API никак не помогут. А ведь такое работает.