Bun переписали с Zig на Rust за шесть дней: что получилось и какие риски остались

Команда Bun переписала 960 тысяч строк кода с Zig на Rust за шесть дней, сохранив 99,8% тестов и уменьшив бинарник на 3–8 МБ. Но проект унаследовал 13 044 блока unsafe, что ставит под вопрос обещания Rust о безопасности.

Bun переписали с Zig на Rust за шесть дней: что получилось и какие риски остались

Bun переписали с Zig на Rust за шесть дней. Что это меняет?

Команда Bun переписала 960 000 строк кода с языка Zig на Rust за шесть дней. Новая версия проходит 99,8 % тестов, бинарник уменьшился на 3–8 МБ, а производительность не упала. Но самое важное — проект вышел из тупика, в который его загнали два года проблем.


Проблема, которая не решалась полгода

В марте 2026 года в репозитории Bun появился issue #33453. Процесс, который должен был стабильно работать на продакшене, за три часа начинал поглощать оперативную память с 1,7 до 14 ГБ. Через 14 часов система зависала, потребляя 23 ГБ виртуальной памяти и 143,8 % CPU.

Причина была известна: Bun использовал форк Zig с собственным аллокатором WebKit Malloc. Команда нашла корень проблемы, но исправление не попадало в upstream Zig. Причина — политика сообщества: форк Zig не принимал патчи от Anthropic, потому что в языке запрещён AI-сгенерированный код.

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


Как переписывали Bun: от ошибок к тестам

Переписывание началось с ветки claude/phase-a-port, где ИИ-ассистент Claude Code генерировал Rust-код, а команда параллельно исправляла ошибки компиляции. Стартовали с 16 000+ ошибок, через шесть дней вышли на 99,8 % прохождение тестов.

Правила были жёсткие:

  • нельзя использовать tokio, rayon и async fn;
  • все unsafe-блоки должны быть задокументированы комментариями SAFETY.

В результате таких блоков набралось 13 044 — цифра, которая заставляет задуматься, что именно выиграли от миграции.

Rust-версия Bun показала нейтральную производительность по сравнению с Zig-форком, а бинарник стал меньше на 3–8 МБ. Но самое неожиданное преимущество — скорость сборки. Rust-версия компилируется быстрее, чем форк Zig Bun, благодаря собственным механизмам параллельной компиляции.

В команде говорят, что закрыли около 200 issues за время переписывания, включая проблемы с памятью и производительностью.


13 044 блока unsafe: временный компромисс или новый риск?

Rust обещает искоренить целые классы багов — use-after-free, double-free, некорректную работу с памятью. Но текущая версия Bun содержит 13 044 блока unsafe, где компилятор не может гарантировать безопасность.

Причина проста: команда переписывала код дословно, сохраняя оригинальную логику. В Zig unsafe использовался для низкоуровневых операций — работа с памятью, FFI, прямые манипуляции с указателями. Убрать эти блоки без переписывания архитектуры было нельзя.

Ещё один фактор — запрет на tokio и rayon. Команда решила не использовать высокоуровневые асинхронные библиотеки Rust, чтобы не усложнять миграцию. Вместо этого пришлось вручную реализовывать асинхронные операции с помощью unsafe, так как компилятор не давал гарантий безопасности.

Получается парадокс: Rust даёт гарантии внутри границ unsafe, но человеческие ошибки — неверные комментарии SAFETY, неучтённые инварианты — могут привести к тем же проблемам, что и в Zig.

Часть комментаторов на Hacker News уже пишет, что такое количество unsafe сводит на нет преимущества Rust. Другие надеются, что после рефакторинга этих блоков код станет безопаснее.


Что это значит для остальных?

Если Rust-версия Bun выйдет в стабильной сборке, это станет первым прецедентом для миграций такого масштаба в экосистеме JavaScript. Команда доказала, что переписывание огромных кодовых баз с одного языка на другой — реально за неделю, если подключить ИИ.

Но главное не скорость, а качество итогового кода.

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

Утечки памяти могут вернуться, если не разобраться с логикой удержания ссылок. А 13 044 блока unsafe — это не гарантия безопасности, а временный компромисс, который ещё предстоит закрыть.

Если ваш проект страдает от нестабильности платформы или политики сообщества, переписывание на Rust может быть решением — но только если вы готовы разобраться с unsafe и долгосрочной поддержкой.

Read more

iperf3: как правильно измерять пропускную способность между серверами

iperf3: как правильно измерять пропускную способность между серверами

iperf3 показывает только то, что способен передать канал между двумя серверами, если не перегружен публичный тестовый сервер, учтены настройки TCP-окна и исключены прокси. Рассказываем, какие метрики отдаёт утилита, как запустить тест и почему её результаты не равны скорости до сайта в интернете.

Когда FPGA-кластер выгоднее подписки: расчёт на реальных цифрах

Когда FPGA-кластер выгоднее подписки: расчёт на реальных цифрах

FPGA-кластер из 72 устройств ускорил взлом FileVault в 498 раз и снизил латентность в банковских контурах до 0,8 мкс, но окупается только при стабильной нагрузке и наличии аппаратной экспертизы. В остальных случаях дешевле арендовать облачные инстансы или подписаться на коммерческие инструменты.

Три подхода к памяти AI-агентов на базе Git: где помогает, а где только перекладывает старые проблемы

Три подхода к памяти AI-агентов на базе Git: где помогает, а где только перекладывает старые проблемы

Memoir, Beads и Mem0 + Valkey обещают AI-агентам память, которая не теряется между сессиями и не загрязняет контекст. Но на практике Git-подобная память не универсальна: одни инструменты экономят токены, другие структурируют факты, третьи управляют задачами.