Hacker News Digest

Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.

Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.

• Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
• Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.

• Fil-C предлагает практически полную безопасность памяти при компиляции существующего кода, но при этом требует пересборки всего пользовательского пространства, включая системные библиотеки, что делает его практически неприменимым для больших проектов.
• Появление Fil-C вызвало дискуссию о том, что языки вроде Rust и Go уже предлагают безопасность памяти без необходимости переписывать весь код, и что Fil-C не предлагает ничего нового для новых проектов.
• Некоторые участники обсуждения отметили, что Fil-C не поддерживает FFI, что делает невозможным использование C-библиотек, что является критическим для большинства проектов.
• Другие участники подчеркнули, что Fil-C не предлагает никаких преимуществ для новых проектов, так как он не предлагает ничего нового, что не может быть достигнуто с помощью других инструментов.

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.

• Появление аппаратной поддержки тегирования памяти в x86-64 — это ответ на уже существующие технологии ARM64 (MTE) и Apple (MIE), а не новая идея.
• Технически это не более чем перенос существующих подходов на x86-64, но важно, что это может быть сделано опционально и не сломает существующий код.
• Поддержка тегирования памяти в x86-64 может быть реализована в виде набора инструкций, которые будут использоваться компилятором и стандартной библиотекой, чтобы обеспечить безопасность кода, написанного на C/C++.
• Это не решит проблему безопасности памяти в целом, но может помочь в обнаружении ошибок и предотвращении эксплойтов.

Выбор между Ada, SPARK и Rust вместо C/C++ зависит от целей проекта. C/C++ остаются стандартом для встраиваемых систем из-за привычной экосистемы и обученных кадров, но они несут риски для безопасности — десятилетия разработок не сделали их по-настоящему безопасными без значительных затрат.

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

• Участники обсуждают сравнительные преимущества систем типизации в Ada и Rust, включая возможность создания отдельных типов для единиц измерения (например, мили и километры) для предотвращения ошибок.
• Высказываются мнения о применимости языков (C++, Ada, Rust, SPARK, Zig, D) в высоконадёжных и критических системах, таких как аэрокосмическая отрасль, с акцентом на строгие процессы разработки и верификации, а не только на выбор языка.
• Поднимается тема, что безопасность кода зависит в большей степени от методологии разработки и тестирования (интеграционного, системного), чем от самого языка программирования.
• Обсуждается эргономика и удобство использования возможностей языков (например, newtype в Rust, контролируемые типы в Ada) для обеспечения типобезопасности и предотвращения ошибок на этапе компиляции.
• Некоторые участники выражают скептицизм по поводу необходимости замены C/C++, предлагая вместо этого лучше изучать и использовать существующие языки, совершенствуя навыки и процессы разработки.

В репозитории представлено детальное сравнение решений Advent of Code 2023, где анализируются подходы к решению задач, эффективность кода и производительность. Основное внимание уделено различиям в алгоритмах и структурах данных, используемых участниками, а также их влиянию на время выполнения и потребление памяти.

Приводятся конкретные примеры кода на разных языках программирования, демонстрирующие оптимизации и trade-offs. Упоминаются ключевые инсайты, такие как важность выбора правильных структур данных для сокращения сложности алгоритмов. Это полезно для разработчиков, стремящихся улучшить свои навыки решения алгоритмических задач.

• Участники отмечают сильные стороны Ada, такие как ограниченные числовые типы для предотвращения ошибок, выразительная система типов и удобочитаемость, но сожалеют о его недостаточном распространении вне сообщества safety-critical разработки.
• Rust ценится за безопасность памяти, фокус на надежности и растущую экосистему, но критикуется за отсутствие формальной спецификации (хотя она сейчас разрабатывается) и сложность с компилятором и асинхронностью.
• Поднимаются вопросы о различиях в подходах к строкам (Ada использует массивы символов, Rust — UTF-8), многопоточности (встроенные потоки vs. async) и индексации массивов (произвольные типы в Ada vs. словари в Rust).
• Обсуждаются практические аспекты: скорость компиляции, поддержка Unicode, необходимость спецификаций и влияние экосистемы (инструменты, библиотеки) на выбор языка.
• Упоминаются нишевые применения Ada (например, в 3D-печати) и потенциальные заимствования его функций (ограниченные типы) в другие языки, такие как Rust, C++ и Nim.

Отмена в асинхронном Rust — мощный, но сложный механизм. В синхронном коде отмену часто реализуют через проверку флагов или паники с особыми типами, но это плохо масштабируется. В асинхронной версии проблема глубже: при использовании timeout с операциями вроде tx.send сообщение может быть потеряно, если таймаут сработает во время ожидания места в канале. Это происходит потому, что будущее отменяется на определённой точке приостановки (await), не гарантируя отката уже выполненных действий.

Корень проблемы — в семантике отмены: асинхронные задачи прерываются в состоянии ожидания, но не отменяют побочные эффекты (например, частично отправленные данные). Это приводит к тонким багам, особенно при работе с ресурсами вроде каналов или сетевых соединений. Решения включают аккуратное проектирование API с явной поддержкой отмены, использование деструкторов для очистки и внедрение идиом вроде "отмены через прерывание" с гарантиями целостности.

• Обсуждаются проблемы безопасности отмены (cancel safety) в асинхронном Rust, когда операции могут прерываться в точке .await, что приводит к неожиданным побочным эффектам и потере данных.
• Поднимается вопрос о необходимости "асинхронного Drop" и более строгих гарантий выполнения для критических секций кода, которые не должны прерываться.
• Отмечается, что семантика отмены сильно зависит от контекста, и термин "cancel safety" может вводить в заблуждение, так как не относится к безопасности памяти (safety) в Rust.
• Участники делятся практическими примерами ошибок, связанных с отменой, и предлагают решения, например, буферизацию сообщений или явную пометку функций в документации.
• Обсуждается сложность ручного управления состоянием при реализации асинхронных структур и проводятся параллели с аналогичными проблемами в других языках, например, в Go.

niri — это тайлинговый композитор для Wayland с поддержкой прокрутки, написанный на Rust. Он фокусируется на минимализме, стабильности и производительности, предлагая плавную работу без лишних зависимостей. Композитор поддерживает стандартные функции Wayland, включая XDG-Shell, и обеспечивает настраиваемое управление окнами через конфигурационные файлы.

Проект активно развивается, приветствуются contributions и обратная связь. Особенность niri — сочетание простоты использования с возможностями кастомизации, что делает его привлекательным для пользователей, ищущих альтернативу более сложным композиторам. Эффективность кода на Rust позволяет избежать многих проблем с памятью и безопасностью.

• Пользователи высоко оценили Niri за его скроллируемое тайлинг-менеджмент, который позволяет организовывать окна в непрерывную горизонтальную ленту, что повышает продуктивность по сравнению с традиционными тайлерами (i3, xmonad).
• Отмечается стабильность и производительность Niri (написан на Rust), особенно в сравнении с Hyprland, а также простота настройки и работа на ультрашироких мониторах.
• Обсуждаются недостатки: отсутствие панели для виджетов (батарея, часы), возможность "потеряться" в большом количестве окон, ограниченная конфигурация (ранее — один файл).
• Некоторые пользователи выражают скепсис к скроллируемому тайлингу, предпочитая классический пейджный подход (рабочие столы), и сомневаются в готовности Wayland.
• Упоминаются возможные альтернативы и дополнения: COSMIC (желание добавить скроллируемый тайлинг), расширения для Hyprland (hyprscrolling), PaperWM для GNOME.

DARPA запускает программу TRACTOR для автоматизированного перевода уязвимого наследуемого кода на C в безопасный язык Rust. Проблема памяти — наиболее распространённый тип уязвимостей, возникающих из-за прямого управления памятью в C и неопределённого поведения. Несмотря на осознание проблемы, масштабный ручной переписывание кода был невозможен из-за огромного объёма legacy-систем, включая критическую инфраструктуру и оборонные проекты.

Программа использует прорывы в машинном обучении, включая большие языковые модели, для автоматизации перевода с сохранением идиоматичности и качества Rust-кода. TRACTOR будет сочетать статический и динамический анализ с ИИ, проводя публичные соревнования для тестирования решений. Цель — устранить целый класс уязвимостей безопасности, переложив ответственность с программиста на язык, который принудительно обеспечивает корректность работы с памятью.

• Критика синтаксиса Rust и его неидиоматичности для некоторых задач по сравнению с TypeScript, C#, Go или Python, при признании превосходства его инструментов (Cargo, система сборки).
• Обсуждение возможности создания безопасной реализации C (как Fil-C) и аргументы, что проблема не в языке, а в выборе реализации, жертвующей безопасностью ради производительности.
• Сомнения в эффективности автоматической трансляции C/C++ в Rust и риске получения "C с акцентом Rust" вместо идиоматического и безопасного кода.
• Дебаты о применимости Rust в оборонной сфере и его сравнение с другими языками (Zig, Go) по простоте сборки, зависимостям и размеру стандартной библиотеки.
• Споры о философии дизайна Rust: фокус на композиции вместо наследования, сложности borrow checker и несовместимости некоторых идиом C++ с моделью безопасности Rust.

Safepoints — это ключевой механизм синхронизации в Fil-C и других виртуальных машинах, обеспечивающий безопасность памяти в многопоточной среде. Они позволяют потокам делать предположения о состоянии VM и сообщать о своём текущем состоянии, что критично для точного сборщика мусора, отладки и профилирования. Без safepoints не было бы возможности безопасно сканировать стеки, обрабатывать сигналы или использовать fork.

Fil-C вставляет pollchecks — проверки на необходимость остановки — на каждом обратном ребре управления в коде. Это короткая инструкция вроде testb, которая при срабатывании переходит к медленному пути обработки. Такой подход гарантирует, что GC может прервать поток только в безопасных точках, избегая проблем с регистрами или векторными инструкциями, и сохраняя корректность без invasive изменений в компиляторе.

• Fil-C использует механизм pollchecks для остановки потоков (stop-the-world), что необходимо для корректной работы fork(2), но поддержка vfork(2) пока отсутствует и требует нестандартных решений.
• Внедрение safepoint-ов в ассемблерный код рискованно и может нарушить предположения Fil-C о безопасности памяти; в долгосрочной перспективе планируется создать способ написания безопасного ассемблерного кода.
• Подход Fil-C к сборке мусора с опросом точек остановки (polling) создает нагрузку в tight loops, что решается разными оптимизациями (например, разверткой циклов), в отличие от асинхронных сигналов в Go.
• Мнения о читаемости и понятности реализации Fil-C разделились: одни участники находят ее интересной и хорошо объясненной, другие признаются, что не до конца понимают детали.
• Утверждение, что Java использует исключительно compacting GC, является упрощением, учитывая множество доступных конфигураций сборщика мусора в разных реализациях JVM.

Safe C++ больше не развивается.
Год назад появился черновик, обещавший «ржавую» безопасность без ломки старого кода: память, типы, потоки — всё через явный safe-контекст. Комитету идея не зашла: модель Rust назвали чуждой, голоса отдали Profiles — набору ограничений на уже существующий C++, которые на этапе компиляции блокируют UAF, data-race, deadlock, утечки.

Profiles не добавляют синтаксиса, только запрещают опасные паттерны; включаются опцией, обратно совместимы. Safe C++ требовал новых квалификаторов и заимствовал проверки времени жизни — слишком радикально.

Автор Safe C++, Шон Бакстер, признал:

Дальнейшая работа бесполезна; все силы — в Profiles.

Вывод: Profiles слабее, но реалистичнее; ждём их в C++26.

• Комитет C++ фактически отверг Safe C++ и ограничился «Profiles» — набором флагов, запрещающих часть небезопасных конструкций.
• Участники сходятся: главная проблема не техническая, а культурная — сообщество не хочет ограничений, считая «если код работает — значит, он безопасен».
• Profiles критикуют за примитивность: они не решают temporal safety, не выражают лифтаймы и не требуют изменения синтаксиса, поэтому дают лишь иллюзию защиты.
• Большинство считает, что без полного отказа от C-подобного подмножества и без внедрения lifetimes C++ никогда не станет «безопасным»; проще перейти на Rust.
• Практический вывод: крупные проекты продолжат игнорировать Profiles, а новые кодовые базы будут выбирать Rust либо двухъязычный подход «C++26 + внешние анализаторы».

• Эволюция OCaml – Ashoka Univ, сент 2025 [pdf][key]
• Авто-проверка реплиц. типов – NUS, авг 2025 [pdf][key]
• AI-инструменты для исследований – IIT Madras, июль 2025 [pdf][key]
• Параллельный рантайм OCaml – Chalmers, май 2025 [pdf][key]
• Авто-проверка реплиц. типов – WG 2.8, май 2025 [pdf][key]
• Параллельный OCaml 5 – Bloomberg, мар 2025 [pdf][key]
• Параллельный OCaml 5 – IIT Gandhinagar, мар 2025 [pdf][key]
• Параллельный OCaml 5 (ч.1) – PACE Lab, фев 2025 [pdf][key]
• Безопасность памяти и ЯП – Schaeffler @ IITM, фев 2025 [pdf][key]
• Мини-ОС через Unikernels – Daekin–IITM, янв 2025 [pdf][key]
• Безопасные Unikernels с аппаратной поддержкой – CAIR DRDO, ноя 2024 [pdf][key]
• Параллельный OCaml 5 – Meta London, сен 2024 [pdf][key]
• Зачем OCaml? – Rezilyens, авг 2024 [pdf][key]
• Эффекты и конкурентность – Chalmers, май 2024 [pdf][key]
• Безопасность функциональных программ – WG 2.8, апр 2024 [pdf][key]
• Композиция библиотек конкурентности – EHOP, июл 2023 [pdf][key]
• Сливаемые реплиц. типы – Collège de France, апр 2023 [pdf][key][видео]
• OCaml 5.0 – OCaml Workshop, сен 2022 [pdf][key]
• Ретрофит конкурентности – ICFP keynote, сен 2022 [pdf][key][видео]
• Сертифицированные сливаемые типы – PLDI, июн 2022 [pdf][key][видео]
• Сертифицированные сливаемые типы – Nomadic Labs, апр 2022 [pdf][key][видео]
• Параллелизм в OCaml – Marigold, дек 2021
• Эффекты в OCaml 5 – Huawei STW, окт 2021 [pdf][key]
• Эффекты в OCaml – SimCorp, сен 2021 [pdf][key]
• Параллелизм в OCaml – SimCorp, сен 2021 [pdf][key]
• ParaFuzz: фаззинг многопоточных программ – Dagstuhl, 2021

• Доклад — субъективный взгляд на 10-летнюю эволюцию OCaml; цель — убрать мистику вокруг разработки компилятора и заманить новых контрибьюторов.
• Главный бытовой pain-point: в стандартной библиотеке исключения — часть API, и они не типизированы, что подрывает «безопасность» языка.
• Выход — использовать Jane Street Core/Base (функции либо возвращают Result, либо помечены _exn), но большинство проектов всё ещё живёт на обычной Stdlib.
• «Большие» альтернативы Stdlib (Core, Base) существуют, но их значение часто преувеличено; официальная библиотека за последние годы всё-таки подросла полезными функциями.
• Новичкам в компиляторщине советуют начинать с мелких багов и мини-Pull Request’ов, а не пытаться сразу «съесть слона».

• Zig вызывает интерес благодаря мощному comptime и «inline else», позволяющим абстрагироваться без рантайм-оверхеда.
• Участники сравнивают его метапрограммирование с C, D и Rust, отмечая, что похожие идеи уже были, но Zig может сделать их популярнее.
• Главный упрек Zig — отсутствие гарантий memory- и data-race safety, из-за чего многие считают его неподходящим для многопоточного кода.
• «comptime unreachable» воспринимается как способ доказать компилятору недостижимость кода, а не как runtime-assert.
• Некоторые считают, что язык ещё нестабилен и экосистема незрела, поэтому широкое внедрение отложено.