Когда bun обещает завтра снова

Самое грустное в смене технологий — когда кто-то сжигает то, что уже работало. Bun когда-то выглядел как редкий случай: быстрая JavaScript-среда, написанная одним человеком, которая всерьёз бросила вызов Node.js. Но затем начались обещания, переносы и переписывание, после которого стало не яснее, а тревожнее.

История проваленных обещаний

В июне 2024 года Jarred Sumner пообещал релиз Bun v1.4 на 7 июля. Потом дата сдвинулась на следующий вторник. Потом — на следующую неделю. Потом — «завтра».

К концу августа стабильного релиза всё ещё не было. Для проекта это уже не обычная задержка, а затяжной сигнал о том, что процесс разваливается прямо на глазах.

ОБЕЩАНИЯ BUN V1.4
──────────────────
Июнь 24  ──▶  "Релиз 7 июля"
Июль 7   ──▶  (дата прошла)
Июль 14  ──▶  "В следующей версии"
Июль 20  ──▶  "В следующей версии"
Август 4 ──▶  "В следующей версии"
Август 7 ──▶  "Ещё один PR — и всё!"
Август 13 ──▶  "Компилируется..."
Август 17 ──▶  "Ну, наверное, завтра"
           ──▶  (тишина)

Когда такие задержки повторяются, возникает простой вопрос: проблема в процессе или в самой архитектуре? В случае Bun, похоже, есть и то и другое.

Переписывание на RUST зачем и почему

Bun родился на Zig. Это был осознанный выбор: быстрые сборки, низкий порог входа и прямой контроль над памятью. Для маленькой команды это выглядело идеально.

Позже Jarred объявил о переписывании Bun на Rust. Формальная причина — memory safety, то есть защита от ошибок работы с памятью. Rust действительно даёт сильные гарантии, а Zig оставляет больше ответственности на программисте.

Но на этом фоне особенно жёстко прозвучала оценка от Andrew Kelley, создателя Zig, который назвал кодовую базу Bun смесью хака на хаках и злоупотребления assertions. Это не похоже на нейтральную критику — скорее на публичный диагноз качеству проекта.

Мы пришли в всё больший ужас от того, что видели в кодовой базе Bun. Хак на хаках. Злоупотребление assertions. Jarred писал говнокод задолго до того, как получил доступ к LLM.

Ai-писатель: кто делает код?

Самый неудобный вопрос здесь — кто именно теперь пишет Bun. По последним данным, основную часть коммитов делают роботы: robobun и autofix-ci[bot]. Jarred Sumner при этом оказывается далеко не первым по объёму изменений.

ПОСТУПЛЕНИЕ КОДА В BUN (последний месяц)
─────────────────────────────────────────
robobun        ████████████████████████████  15,800 коммитов
autofix-ci[bot] ████                        1,600 коммитов
Jarred Sumner  ██                          790 коммитов

Вдобавок у Bun на GitHub сейчас больше 5,000 открытых pull requests. Это уже не очередь на проверку, а склад нерешённых изменений. Для сравнения, у React — сотни, у OpenClang — заметно меньше. GitHub сам рекомендует держать число открытых PR ниже 1,000, иначе начинаются проблемы с mergeability checks.

Unsafe blocks: где RUST подвёл

Rust должен был принести memory safety, но в переписанном коде всё равно остались unsafe blocks — места, где автоматические гарантии отключены. Формально это допустимо, но на практике смысл переписывания заметно размывается.

Вместо истории про безопасный и зрелый переход всё больше похоже на демонстрацию того, как большую часть инженерной работы за людей начинает делать Claude и другие модели, а не сама команда.

Что в итоге?

Bun рискует потерять главное: доверие сообщества и репутацию проекта, который когда-то казался быстрым, ясным и собранным руками одного сильного разработчика.

Зиг давал маленькой команде скорость и контроль. Rust даёт безопасность, но требует дисциплины и процесса. Сама смена языка не проблема. Проблема начинается там, где её пытаются компенсировать потоком автогенерируемого кода и бесконечными обещаниями «завтра».

Пока что v1.4 всё ещё где-то впереди.

Ссылки

• Bun 1.4 Rust rewrite is not looking good? — разбор проблем с переписыванием Bun на Rust