Hacker News Digest

Разработчик Ruby-гема Karafka столкнулся с редким, но критическим багом, когда 2700 идентичных ошибок NoMethodError: undefined method 'default' for an instance of String обрушили систему. Ошибка возникала при доступе к elem[:partition] в FFI::Struct, хотя код нигде не использовал метод #default, характерный для Hash.

Исследование показало, что проблема в версиях FFI ниже 1.17.0, где отсутствуют write-барьеры, позволяющие сборщику мусора Ruby освобождать внутренние Hash-объекты. После освобождения память могла перераспределяться под другие объекты, например, строки. Баг проявляется с вероятностью "один к миллиону", но катастрофичен по последствиям. Пользователи использовали Alpine Linux с musl libc, что могло усугубить ситуацию из-за особенностей компиляции и выравнивания структур.

• Обсуждение выявило, что причиной проблемы была давно исправленная ошибка в ffi, а не в Ruby или в коде клиента.
• Участники спора оспаривают, стоит ли считать статью «LLM-шлаком» из-за плохого стиля, даже если сама техническая информация в ней точна.
• Некоторые участники считают, что стиль может быть вызван тем, что автор предпочитает кодить, а не писать, и что технически важная информация была доставлена.
• Другие участники спора отмечают, что статья была полезна и что важно сосредоточиться на техническом содержании, а не на стиле написания.

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

Гибридный PHP: PHP + Go и Rust

Раньше у нас был монолит на PHP 8.3 («мама») и несколько микросервисов на Go («дети»). Такой стек давал скорость там, где нужно, и скорость разработки везде остальном.

По правилу 80/20 20 % эндпоинтов приносят 80 % нагрузки. Раньше мы выносили их в Go-сервисы, но это усложняло инфраструктуру. Теперь можно оставить логику в монолите и всё равно получить высокую производительность.

Новые инструменты

• FFI – вызов C-кода прямо из PHP.
• Расширения на Rust – безопасный и быстрый код без C.
• FrankenPHP – worker-режим до 4× быстрее; теперь можно писать расширения на Go и вызывать их из PHP.

Зачем не переписать всё на Go или Rust?

• Переписывание дорого и рискованно.
• PHP отлично справляется с 80 % задач, а критичные 20 % можно ускорить расширениями на Rust/Go.

Итог: современный PHP даёт и скорость разработки, и максимальную производительность там, где это критично.

• Участники жалуются, что монолитные фреймворки (Spring, Laravel, Phoenix) быстро дают результат, но превращают legacy-код в кошмар при обновлении зависимостей.
• Обсуждают гибридные схемы «PHP + Rust/Go/C», но предупреждают о росте сложности отладки и найма.
• Некоторые считают современный PHP (≥8.x) недооценённым и упрекают индустрию в стереотипах 5.x-времён.
• Упоминаются альтернативные рантаймы (FrankenPHP, RoadRunner, Workerman) и эксперименты с встраиванием PHP в nginx.
• Пакетный менеджер Composer критикуется как «не тот уровень», ждут «Astral для PHP».