Bun переписывают на Rust: почему Zig не оправдал ожиданий
Экосистема разработки на JavaScript и TypeScript переживает фундаментальный сдвиг. Проект Bun, создававшийся как сверхбыстрая альтернатива Node.js и Deno, объявил о радикальном решении: полностью переписать свою кодовую базу с языка Zig на Rust. Это заявление Джареда Самнера, основателя проекта, стало неожиданностью для всей индустрии, ведь изначально именно выбор Zig позиционировался как ключевой фактор невероятной производительности Bun.
На сегодняшний день масштаб проекта огромен — ежемесячно утилита командной строки собирает более 22 миллионов скачиваний, а первый класс хостинг-платформ, включая Vercel, Railway и DigitalOcean, предоставляет встроенную поддержку среды выполнения. Перенос более чем 530 тысяч строк сложнейшего системного кода — это вызов, который показывает реальные границы использования современных языков программирования при создании критически важной веб-инфраструктуры.
Почему Zig не справился со стабильностью
Изначально Zig казался идеальным выбором для Bun. Он предлагал тотальный ручной контроль над памятью, отсутствие скрытого сборщика мусора и бесшовную интеграцию с C-библиотеками. Однако на практике среда выполнения JavaScript — это среда с автоматическим управлением памятью и сборщиком мусора. Для Bun используется движок JavaScriptCore от Apple.
Попытка подружить автоматический сборщик мусора JavaScript с полностью ручным управлением памятью в Zig привела к появлению сотен сложнейших багов, связанных с жизненными циклами объектов. Разработчики регулярно сталкивались с утечками памяти, обращениями к памяти после её освобождения, повторными освобождениями и выходом за границы буферов. Ситуацию усложняло то, что ручное освобождение памяти в Zig при обработке ошибок легко забыть или написать с ошибкой.
Среди типичных багов, с которыми столкнулась команда Bun:
- Состояние гонки при сбросе и записи в модуле сжатия zlib.
- Инвалидация указателей в протоколе HTTP/2 после изменения размера хэш-таблиц.
- Разрушение связей ArrayBuffer в сетевых UDP-сокетах при вызове методов приведения типов.
- Утечки сессий в библиотеке шифрования TLS.
- Ошибки повторного освобождения памяти в парсере стилей CSS.
- Проблемы с конкурентным доступом в механизмах обмена сообщениями BroadcastChannel.
Существовавшие защитные меры — запуск санитайзера адресов на каждый коммит, сборка безопасных релизов на Windows, круглосуточное фаззинг-тестирование с помощью Fuzzilli и сквозное тестирование на утечки памяти — помогали выявлять проблемы, но не предотвращали появление новых. Ручное управление памятью в столь сложном проекте превратилось в постоянный источник нестабильности.
Как Rust решает проблемы безопасности
Переход на Rust позволяет избавиться от целого класса ошибок ручного управления ресурсами благодаря встроенной системе владения, механизму заимствования и автоматической очистке ресурсов при выходе из области видимости. Компилятор Rust гарантирует безопасность работы с памятью на этапе компиляции, избавляя инженеров от необходимости вручную отслеживать освобождение каждого указателя.
При этом полностью безопасным код Bun стать не сможет. Из-за необходимости интеграции со сторонними библиотеками на C и C++ (такими как JavaScriptCore, BoringSSL и SQLite) новая кодовая база содержит множество блоков небезопасного кода. В текущей невыпущенной версии рантайма на Rust уже насчитывается 13 365 unsafe-блоков. Тем не менее, изоляция этих блоков и перенос основной логики под защиту компилятора Rust должны значительно повысить общую стабильность системы.
Роль ИИ в миграции полумиллиона строк
Самой поразительной деталью этого переписывания стала скорость его реализации. Перенос 535 496 строк кода с Zig на Rust занял всего 11 дней. Это стало возможным благодаря использованию передовой модели искусственного интеллекта Claude Fable 5 от компании Anthropic и инструментария Claude Code.
Команда запустила около 50 параллельных динамических рабочих процессов автоматической трансляции кода. Однако успех миграции зависел не только от генерации кода ИИ. Ключевую роль сыграли:
- Огромная база существующих тестов, не зависящих от языка реализации.
- Жёсткий процесс перекрёстного автоматического ревью, когда одна модель ИИ проверяла код, написанный другой.
- Быстрое устранение несоответствий в поведении функций.
Начальный этап миграции преследовал цель механического переноса логики один в один, чтобы избежать расхождений в поведении рантайма. Полноценный рефакторинг с использованием идиоматичного Rust-кода начнется только после релиза стабильной версии Bun v1.4 или v2.
Результаты независимого аудита безопасности
Для проверки надежности новой версии команда инициировала аудит безопасности, результаты которого подтверждают резкое снижение числа спонтанных падений процесса. Дополнительным подтверждением жизнеспособности концепции стал практический эксперимент компании Prisma Compute. Разработчики развернули бета-версию Bun на Rust в своей инфраструктуре и зафиксировали отсутствие утечек памяти в долгосрочных сценариях тестирования при сохранении исходного уровня производительности.
Что делать разработчикам
На данный момент стабильная версия Bun по-прежнему собирается из кода на Zig. Переход на Rust будет постепенным. Разработчикам, использующим Bun в продакшене, рекомендуется:
- Отслеживать появление официальных бета- и canary-сборок на Rust.
- Запускать собственные тестовые сценарии на новых сборках рантайма перед обновлением.
- Особое внимание уделять нагрузочному тестированию операций ввода-вывода (HTTP-запросы, веб-сокеты, работа с файловой системой), так как именно эти компоненты претерпевают наибольшие изменения при переписывании на новый язык.
В долгосрочной перспективе этот шаг сделает Bun гораздо более привлекательным выбором для крупных корпоративных систем, где стабильность рантайма является главным приоритетом, а отладка трудновоспроизводимых низкоуровневых ошибок памяти отнимает слишком много дорогих инженерных ресурсов. Команда проекта показала пример того, как современные языковые инструменты и искусственный интеллект могут коренным образом изменить скорость эволюции критической инфраструктуры разработки.