Hacker News Digest

SourceFS — высокопроизводительная виртуальная файловая система, которая ускоряет сборку Android в 9 раз, снижает вычислительные затраты в 14 раз и уменьшает использование диска в 83 раза. Современные кодовые базы огромны: Linux содержит 40 миллионов строк кода, Android AOSP — 140 миллионов+, а автомобильные системы — до 500 миллионов строк. Медленные сборки и выгрузки кода отнимают часы времени разработчиков и милли долларов на CI-ресурсах.

SourceFS виртуализирует всё, материализуя файлы по требованию, что ускоряет выгрузку кода более чем в 10 раз. Система создает виртуальное представление всей кодовой базы и материализует файлы только при необходимости, экономя сотни гигабайт дискового пространства. Для сборки SourceFS использует легковесные песочницы, записывая все шаги и повторяя их для идентичных операций. В результате сборка ускоряется до 10 раз, а на обычном разработческом компьютере — более чем в 9 раз по сравнению с традиционными методами.

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

jacobly0 предлагает полностью переписать линкер Zig с нуля, создав Elf2 вместо текущей реализации. Основная цель — повысить производительность, уменьшить потребление памяти и улучшить поддержку различных форматов объектных файлов. Новая архитектура позволит эффективнее обрабатывать символы, секции и релокации, избегая проблем существующего кода.

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

• Участники высоко оценивают Zig как компилятор для C/C++ и инструмент кросс-компиляции за его простоту и самодостаточность.
• Отмечается мощная вертикально интегрированная система сборки Zig, включающая линкер и бэкенды генерации кода, что открывает возможности для оптимизаций.
• Обсуждаются ограничения использования линкера Zig (elf2) и самого компилятора вне экосистемы Zig, а также отсутствие неструктурированного goto.
• Некоторые пользователи выражают смешанные чувства: язык делает многое правильно, но отдельные изменения и особенности вызывают сомнения.
• Упоминается книга "Linkers and Loaders" и общее оживление в области разработки линкеров (ренессанс).

Краткий обзор проблемы C++ модулей

1. Главное требование
   Если модули не ускоряют сборку минимум в 5 раз (желательно 10×) на реальных проектах, их нужно удалить из стандарта. Все остальные плюсы не стоят вложенных ресурсов.

2. Что обещали vs. что получили

   • Изначально: «уберём O(N²) из-за заголовков, компиляция станет мгновенной».
   • Сейчас: упор сместился на «изоляцию сборки» (макросы, пространства имён). Это полезно, но редко встречается и не решает главную боль — медленную сборку каждый день.

3. Почему всё так плохо

   • Модули приняли в C++20, несмотря на предупреждения о невозможности реализации.
   • Реализация заняла >5 лет и всё ещё не готова.
   • Стандарт не описывает, как именно компилятор и сборочная система должны взаимодействовать: имена файлов, каталоги, зависимости — всё на совести разработчиков.
   • Компиляторные команды отказываются «превращаться в систему сборки» и блокируют любые предложения.

4. Итог
   Проект превратился в «интеграционный ад». Пока нет массовых 5-10-кратных ускорений, дальнейшие инвестиции — просто затягивание «затратной ямы».

• Участники сетуют: вместо простого «import = include без утечек контекста» получили громоздкий механизм, который мало кто использует.
• Старые пре-компил-хедеры 90-х и сторонние решения вроде zapcc уже давали 5× ускорение, но были проигнорированы стандартом.
• Модули обещали избавить от forward-declaration и макро-ifdef, но на практике вызывают лавину пересборок и несовместимы с большим объёмом существующего кода.
• Многие считают, что модули заточены под «большой тех» с кэшированными билдами, а малый бизнес и хобби-проекты «попали в пролёт».
• Итоговое настроение: «убейте модули, C++ всё сломали», «мир ушёл в Rust», но «на C++ всё ещё держится пол-мира, так что просто так не выкинешь».

Современные CI-платформы стали мощнее, но и сложнее. GitHub Actions, GitLab и др. предлагают YAML-конфиги с шаблонами, условиями, секретами, кешем, артефактами, экосистемой actions — в итоге CI превращается в полноценную систему сборки.

Базовые примитивы (задачи, зависимости, шаги) не отличаются от Makefile-ов, а добавление распределённого запуска и кеша делает CI почти идентичным современным билд-системам вроде Bazel.

Сложность растёт:

• YAML становится языком программирования.
• Пользователи копируют чужие конфиги, не понимая, что происходит.
• Платформы закрываются на собственных экосистемах, создавая vendor lock-in.

Итог: вместо простого «удалённого запуска тестов» мы получили громоздкую систему, где границы между CI и build-системой стёрлись.

• Участники сходятся во мнении, что современные 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.