What to do with C++ modules? 💬 Длинная дискуссия
Краткий обзор проблемы C++ модулей
-
Главное требование
Если модули не ускоряют сборку минимум в 5 раз (желательно 10×) на реальных проектах, их нужно удалить из стандарта. Все остальные плюсы не стоят вложенных ресурсов. -
Что обещали vs. что получили
- Изначально: «уберём O(N²) из-за заголовков, компиляция станет мгновенной».
- Сейчас: упор сместился на «изоляцию сборки» (макросы, пространства имён). Это полезно, но редко встречается и не решает главную боль — медленную сборку каждый день.
-
Почему всё так плохо
- Модули приняли в C++20, несмотря на предупреждения о невозможности реализации.
- Реализация заняла >5 лет и всё ещё не готова.
- Стандарт не описывает, как именно компилятор и сборочная система должны взаимодействовать: имена файлов, каталоги, зависимости — всё на совести разработчиков.
- Компиляторные команды отказываются «превращаться в систему сборки» и блокируют любые предложения.
-
Итог
Проект превратился в «интеграционный ад». Пока нет массовых 5-10-кратных ускорений, дальнейшие инвестиции — просто затягивание «затратной ямы».
Комментарии (165)
- Участники сетуют: вместо простого «import = include без утечек контекста» получили громоздкий механизм, который мало кто использует.
- Старые пре-компил-хедеры 90-х и сторонние решения вроде zapcc уже давали 5× ускорение, но были проигнорированы стандартом.
- Модули обещали избавить от forward-declaration и макро-ifdef, но на практике вызывают лавину пересборок и несовместимы с большим объёмом существующего кода.
- Многие считают, что модули заточены под «большой тех» с кэшированными билдами, а малый бизнес и хобби-проекты «попали в пролёт».
- Итоговое настроение: «убейте модули, C++ всё сломали», «мир ушёл в Rust», но «на C++ всё ещё держится пол-мира, так что просто так не выкинешь».
Modern CI is too complex and misdirected (2021) 💬 Длинная дискуссия
Современные CI-платформы стали мощнее, но и сложнее. GitHub Actions, GitLab и др. предлагают YAML-конфиги с шаблонами, условиями, секретами, кешем, артефактами, экосистемой actions — в итоге CI превращается в полноценную систему сборки.
Базовые примитивы (задачи, зависимости, шаги) не отличаются от Makefile-ов, а добавление распределённого запуска и кеша делает CI почти идентичным современным билд-системам вроде Bazel.
Сложность растёт:
- YAML становится языком программирования.
- Пользователи копируют чужие конфиги, не понимая, что происходит.
- Платформы закрываются на собственных экосистемах, создавая vendor lock-in.
Итог: вместо простого «удалённого запуска тестов» мы получили громоздкую систему, где границы между CI и build-системой стёрлись.
Комментарии (159)
- Участники сходятся во мнении, что современные CI-системы слишком сложны и слишком «далеко» от разработчика, превращаясь в гибрид билд-системы и платформы.
- Многие предлагают упрощение: локально-переносимые скрипты (Bash, Justfile, build.bash), контейнеры или минималистичные движки вроде builds.sr.ht, Drone OSS, Buildbot, Linci.
- Критика YAML-конфигураций и SaaS-зависимости: GitHub Actions «застрял», GitLab CI мощнее, но всё равно требует «платформы».
- Идея «CI должен быть просто расширением билд-системы» (Bazel, Nix, Dagger) звучит, но требует единого «Steve Jobs билд-систем», а не новых технологий.
- Итог: пока нет серебряной пули; кто хочет простоты — пишет ./build.sh и запускает где угодно, кто хочет мощности — мирится с уровнем сложности текущих CI.