Bun на Rust: AI-порт с Zig за 11 дней — 6502 коммита
Анализ · 15 июля 2026

Bun переписан на Rust:
64 AI-агента перенесли 535K строк за 11 дней

Джарред Самнер использовал Claude Fable 5 и 64 оркестрированных AI-агента, чтобы переписать Bun с Zig на Rust — 6502 коммита, 128 исправленных багов и бинарник на 20% меньше. Вот как это произошло.

Олег Максимов 15 июля 2026 12 мин чтения

Что произошло

14 мая 2026 года Джарред Самнер объединил пул-реквест, который фундаментально изменил ландшафт JavaScript-рантаймов: Bun был переписан с Zig на Rust. Порт, завершённый за 11 дней, использовал предрелизную версию Claude Fable 5 (Mythos-модель Anthropic) с 64 AI-агентами, работавшими параллельно в 4 рабочих директориях.

Результат: 6502 коммита, 0 пропущенных или удалённых тестов, 128 исправленных багов, бинарник на 20% меньше, производительность на 2-5% выше и значительно сниженное потребление памяти. Bun v1.3.14 стал последней версией на Zig; v1.4.0 — первый релиз на Rust, доступный в canary прямо сейчас.

11
Дней от старта до слияния
6 502
Коммитов
~64
Одновременных AI-агентов

Почему Bun начинался на Zig

Bun начинался как построчный порт транспилятора esbuild с Go на Zig. Джарред Самнер написал свою первую строку на Zig 16 апреля 2021, вдохновившись одностраничной документацией языка и его контролем над производительностью. Без Zig Bun никогда не был бы создан — простота языка и comptime позволили одному разработчику за год создать массивный рантайм до эры LLM.

Масштаб Bun был огромен с самого старта: транспилятор JavaScript, TypeScript и CSS; минификатор и бандлер; npm-совместимый пакетный менеджер; тест-раннер как Jest; Node.js-совместимое разрешение модулей; HTTP/1.1 и WebSocket клиент; десятки реализаций Node.js API. Сегодня CLI Bun получает более 22 млн загрузок в месяц, а Claude Code и OpenCode используют его как рантайм.

Почему Zig перестал быть достаточным

Проблемы стабильности Bun коренились в фундаментальном противоречии: JavaScript управляется сборщиком мусора, а Zig (как C) не управляет памятью автоматически. Смешение этих двух парадигм в одном проекте настолько редкое явление, что ни один язык не проектируется для него. Результатом стал постоянный поток багов памяти, которые не могли полностью предотвратить никакие инструменты.

Вот лишь несколько примеров багов, исправленных в Bun v1.3.14:

Команда уже делала больше, чем многие проекты: патчила Zig для поддержки Address Sanitizer, выпускала ReleaseSafe-сборки на Windows, круглосуточно фаззила Fuzzilli и проводила всесторонние тесты утечек памяти. Но, как сказал Джарред: «Я устал ложиться спать и беспокоиться о крашах Bun».

Почему именно Rust?

Решение портировать на Rust — а не на C++ (который уже составлял 20% кодовой базы Bun) — сводилось к одному: гарантии на этапе компиляции вместо руководств по стилю.

В Zig очистка ресурсов полагается на defer и errdefer в каждом месте вызова. В Rust трейт Drop выполняется автоматически при выходе значения из области видимости. Разница фундаментальна: Zig требует помнить о добавлении кода очистки; Rust гарантирует его выполнение каждый раз. Для кодовой базы, смешивающей GC-управляемую и ручную память, такая систематическая гарантия устраняет целые категории багов.

Язык Механизм очистки Контроль Влияние на стабильность
Zig defer, errdefer Вручную на каждом вызове Легко забыть или выполнить дважды
C++ ~Destructor, &&Move Автоматически через RAII Лучше, но всё ещё есть пробелы
Rust Drop Гарантируется компилятором Use-after-free и double-free — ошибки компиляции

Кроме Drop, Rust даёт команде Bun: борроу-чекер (безопасность памяти на этапе компиляции), Miri (экспериментальный интерпретатор для обнаружения неопределённого поведения) и LeakSanitizer (отслеживание всех аллокаций нативного кода). Эти инструменты работают в CI и ловят проблемы до того, как они попадут в продакшен.

AI-ассистированная перезапись: Как работали 64 агента

Изначально Джарред планировал добавить вдохновлённые Rust умные указатели в Zig-код Bun. Но после размышлений об эргономике он решил потратить неделю на тестирование возможности переписать Bun на Rust через новую модель Anthropic. Через несколько дней значительная часть тестов начала проходить, и мнение сменилось с «стоит попробовать» на «я это объединю».

Подготовка: PORTING.md и LIFETIMES.tsv

Перед написанием кода Джарред потратил около 3 часов на обсуждение с Claude того, как отображать Zig-паттерны на Rust. Результат был сериализован в PORTING.md, который позже попал на Hacker News. Затем динамический воркфлоу проанализировал каждое поле каждой структуры во всей кодовой базе, отследил поток управления, предложил времени жизни и отправил каждое предложение на проверку 2 состязательным ревьюерам. Результат: LIFETIMES.tsv — структурированная спецификация времён жизни для всей кодовой базы.

Динамические воркфлоу: Циклы, которые пишут и ревьюят код

Ключевая идея порта — представление инженерной работы как цикла:

// Псевдокод — цикл, управляющий перезаписью: let task; while ((task = todoList.pop())) { const result = task(); const feedback = await Promise.all([review(result), review(result)]); await apply(feedback, result); }

Около 50 динамических воркфлоу работали непрерывно в течение 11 дней. Каждый воркфлоу был циклом для конкретной цели: генерация руководства по портированию, механический перевод .zig в .rs, исправление ошибок компилятора, запуск подкоманд, прохождение тестов. Джарред мониторил воркфлоу — читал выводы, проверял наличие проблем и редактировал циклы, когда что-то шло не так.

Состязательное ревью кода: Раздельные контекстные окна

Самая инновационная часть подхода — паттерн состязательного ревью с раздельными окнами. Для каждой задачи портирования:

Разделение предотвращает предвзятость подтверждения, возникающую, когда один и тот же агент пишет и ревьюит код. Ревьюеры ловили реальные баги, которые компилировались чисто и выглядели корректно:

Параллелизация: 64 Claude в 4 рабочих директориях

На пике перезапись использовала 16 Claude на воркфлоу, в 4 отдельных git worktree — всего 64. Первая попытка провалилась, потому что Claude мешали друг другу командами git stash и git reset. Джарред добавил правило: никаких git-команд, кроме фиксации конкретного файла за раз. Никакого cargo. Никаких медленных команд.

На пике пропускной способности Claude писал около 1300 строк кода в минуту. Каждая строка проверялась двумя состязательными ревьюерами перед коммитом. Самый активный час: 695 коммитов.

Ошибки компилятора как очередь задач

После написания всего кода следующей задачей было исправление ~16 000 ошибок компиляции. Подход был элегантно прост: каждая ошибка компилятора — задача в очереди работ. cargo check записывал ошибки в файл, сгруппированные по крейтам. 64 Claude распределяли их между 4 worktree.

Самыми сложными были циклические зависимости. Zig-кодовая база была одной единицей компиляции (фактически одним крейтом), но Rust нужно было ~100 крейтов для быстрой компиляции. Воркфлоу классифицировал, куда должен идти код с циклическими зависимостями, а затем другой воркфлоу выполнял рефакторинг. Это выявило ~16 000 ошибок — огромное число для одного человека, но не проблема для 64 Claude.

Ложные старты и улучшения процессов

Несколько ложных стартов потребовали корректировки промптов:

Результаты: Что изменилось

128 исправленных багов

Bun v1.4.0 исправляет 128 багов, воспроизводимых в v1.3.14 — от утечек памяти и крашей до некорректного цвета текста. Самое значительное — утечка памяти в Bun.build():

Сборок Bun v1.3.14 (Zig) Bun v1.4.0 (Rust)
500 1 914 MB 526 MB
1 000 3 506 MB 586 MB
1 500 5 097 MB 608 MB
2 000 6 745 MB 609 MB

В v1.3.14 каждая Bun.build() теряет ~3 MB — dev-серверы, собирающие проект на каждый запрос, со временем исчерпывают память. В v1.4.0 память стабилизируется на ~600 MB. Предыдущая попытка исправить это в Zig не была объединена — отсутствие аналога Drop делало это слишком рискованным.

Бинарник на 20% меньше

Порт на Rust в сочетании с изменениями ICU и Identical Code Folding уменьшил бинарник Bun примерно на 20%:

Платформа Bun v1.3.14 (Zig) Bun v1.4.0 (Rust) Уменьшение
Linux 88 MB 70 MB ~20%
Windows 94 MB 76 MB ~19%

Производительность на 2-5% выше

Rust поддерживает кросс-языковую LTO между C/C++ и Rust, что позволяет встраивать код между языками — возможность, которой не было в Zig.

Бенчмарк Bun v1.3.14 Bun v1.4.0 Δ
Bun.serve (HTTP) 169.6k req/s 177.7k req/s +4.8%
node:http 103.8k req/s 108.5k req/s +4.5%
next build 13.62 с 13.03 с +4.5%
vite build 1.69 с 1.65 с +2.2%
tsc -b --force 0.94 с 0.89 с +4.7%

Влияние на AI-ассистированную разработку

Порт Bun на Rust — landmark в AI-ассистированной разработке ПО. Цифры говорят сами за себя:

Реалистичная альтернатива была — ничего не делать, продолжать чинить баги вечно. Вместо этого Bun выходит с кодовой базой, имеющей систематически лучшие гарантии стабильности. Как сказал Джарред: «Один инженер может сделать гораздо больше сегодня, чем год назад».

Это тот же паттерн, который мы видели с портом React Compiler на Rust, где AI сгенерировал большинство из 435 коммитов для перевода TypeScript-компилятора на Rust. Разница в масштабе: порт Bun использовал 64 конкурентных агента с состязательным ревью, тогда как порт React Compiler — более обычный AI-ассистированный воркфлоу. Оба демонстрируют, что AI-ассистированное портирование кода жизнеспособно для ключевой инфраструктуры.

Похожие темы AI-генерированного кода в масштабе я разбираю в статье о запрете Fable 5 в open-source.

FAQ

Почему Bun перешёл с Zig на Rust?
Проблемы стабильности Bun были связаны с корректной обработкой времён жизни GC JavaScript и ручным управлением памятью Zig. Несмотря на ASAN, фаззинг и тесты утечек, use-after-free, double-free и утечки памяти повторялись. Борроу-чекер Rust, трейт Drop, Miri и LeakSanitizer дают гарантии на уровне компиляции.
Действительно ли порт Bun на Rust написан AI?
Да. Джарред Самнер использовал предрелизную версию Claude Fable 5 с динамическими воркфлоу Claude Code. На пике 64 экземпляра Claude работали в 4 рабочих директориях, создав 6502 коммита за 11 дней. Общая стоимость составила около $165 000 на API-токены.
Как работает состязательное ревью кода AI?
Каждая задача имела 1 Claude-исполнителя и 2 Claude-ревьюера в отдельных контекстных окнах. Ревьюеры видели только diff и должны были найти баги. Такой подход ловил реальные ошибки: use-after-free в асинхронном uv_close, отрицательные наносекунды в timespec и панику из-за eager вычисления.
Насколько быстрее Bun на Rust по сравнению с Zig?
Bun v1.4.0 на 2-5% быстрее v1.3.14 по HTTP и CLI. Bun.serve +4,8%, node:http +4,5%, next build +4,5%, tsc +4,7%. Ускорение достигнуто благодаря кросс-языковой LTO и лучшему использованию стека.
Насколько уменьшился бинарник Bun?
Бинарник уменьшился примерно на 20%. Linux: 88 MB → 70 MB. Windows: 94 MB → 76 MB. За счёт меньшего comptime, Identical Code Folding и удаления неиспользуемых данных ICU. Для сравнения, JavaScript runtime Ant использует ещё более агрессивный подход — собственный движок на C размером ~8,6 MB.
Исправляет ли порт на Rust реальные баги пользователей?
Bun v1.4.0 исправляет 128 багов, воспроизводимых в v1.3.14. Самое значительное — утечка памяти в Bun.build(): в v1.3.14 каждая сборка теряет ~3 MB. В v1.4.0 память стабилизируется на ~600 MB даже после 2000 сборок.
Порт на Rust уже доступен?
Bun v1.3.14 — последняя версия на Zig. Bun v1.4.0 — первая на Rust, доступна в canary через 'bun upgrade --canary'. Claude Code v2.1.181+ уже работает на Rust-версии Bun.

Нужен опытный веб-разработчик?

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

Я — full-stack веб-разработчик с 20+ годами опыта создания production-приложений. Оцениваете ли вы Bun для своего проекта, мигрируете существующую кодовую базу или нуждаетесь в консультации по современной JavaScript- экосистеме — я готов помочь. Свяжитесь со мной для бесплатной первичной консультации.

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

Контакты

Обсудим ваш проект

Нужен веб-разработчик, который разбирается в современной экосистеме? Расскажите о проекте — я дам честную рекомендацию и предварительную оценку. Бесплатно.