LINUX.ORG.RU

Bun завершил перенос с Zig на Rust, после чего разработчики проектов публично разругались

 , , ,


0

4

Команда Bun завершила перенос основной кодовой базы среды исполнения JavaScript и TypeScript с Zig на Rust. Изменения были влиты в main 14 мая 2026 года, а 8 июля руководитель проекта Джарред Самнер опубликовал отчёт о миграции. Последней стабильной версией на Zig пока остаётся Bun 1.3.14, тогда как Rust-реализация доступна в Bun 1.4 Canary. Порт уже используется в Claude Code начиная с версии 2.1.181 и в публичной бете Prisma Compute.

Перенос затронул 535 496 строк Zig-кода и занял 11 дней. Самнер задействовал около 50 автоматизированных процессов Claude Code, одновременно запускавших до 64 экземпляров Claude. Итоговый diff добавил более миллиона строк и включил 6502 коммита без учёта слияний. По оценке автора, запросы обошлись бы примерно в 165 тысяч долларов по тарифам API; вручную работа потребовала бы трёх разработчиков и около года.

Один ИИ-агент создавал код, два других искали ошибки, ещё один применял исправления. Перед слиянием прежний набор тестов полностью прошёл на шести платформах, причём тесты не удалялись и не пропускались. После переноса команда провела 11 циклов проверки безопасности и запустила непрерывный фаззинг парсеров.

Причиной миграции разработчики называют не недостатки Zig как такового, а устройство Bun. Среда объединяет JavaScriptCore со сборкой мусора и нативный код с ручным управлением памятью, что приводило к утечкам, use-after-free и double-free. Rust позволяет обнаруживать часть таких ошибок раньше и освобождать ресурсы через Drop. По данным команды, Bun 1.4 исправляет 128 ошибок из 1.3.14, уменьшает бинарник примерно на 20% в Linux и Windows и в отдельных тестах работает на 2–5% быстрее.

Порт пока далёк от идиоматического Rust: около 4% кода находится внутри unsafe — примерно 27 тысяч строк и 13 тысяч употреблений ключевого слова. Кроме того, были обнаружены 19 известных регрессий, которые, по утверждению разработчиков, уже исправлены.

На следующий день основатель Zig Эндрю Келли опубликовал резкий ответ. По его мнению, проблемы Bun возникли не из-за модели памяти Zig, а из-за инженерной культуры проекта: слишком быстрого добавления функций, накопления технического долга и злоупотребления comptime и assert. Келли утверждает, что Zig Software Foundation неоднократно пыталась обратить внимание команды Bun на качество кода.

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

Другие претензии касаются результатов. Келли отметил, что прирост скорости связывается с межъязыковой LTO, хотя Zig тоже поддерживает LTO. Сокращение бинарника частично обеспечили оптимизация ICU и настройки линковки, а сравнение времени компиляции в отчёте отсутствует. Он также увидел противоречие между рассказом о фаззинге и прежними разговорами, в которых команда Bun якобы сообщала, что фаззинг не используется.

Технический спор быстро перешёл в конфликт между проектами. По словам Келли, компания Oven перечисляла Zig Software Foundation около 60 тысяч долларов в год, но после покупки Bun компанией Anthropic выплаты прекратились, а представители Bun не пришли на регулярную встречу. Он также раскритиковал управленческий стиль Самнера, ссылаясь на рассказы бывших работников и соискателей. Независимых подтверждений этим обвинениям опубликовано не было.

Позднее Келли изменил заключение статьи и признал, что накопившаяся обида сделала текст похожим на личную атаку. Таким образом, перенос Bun на Rust технически завершён и уже применяется, хотя стабильный выпуск Bun 1.4 ещё впереди. Сам конфликт оказался не столько спором Zig против Rust, сколько столкновением взглядов на темп разработки, роль ИИ и способы обеспечения качества открытого проекта.

Bun – это среда выполнения ECMAScript / JavaScript, по многим параметрам аналогичная nodejs. Bun старается быть максимально совместимым с nodejs по опциям командной строки, поддерживает модули ECMAScript (ESM) и CommonJS. Управление пакетами npm и поддержка typescript встроены прямо в приложение как нативный код, и программы на typescript могут исполняться напрямую интерпретатором без предварительной конфигурации.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)
Ответ на: комментарий от BruteForce

Было 500000 строк, стало 1000000?

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

появились регрессии

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

Может тебе ещё посидеть? С чтением текстов у тебя не очень, но зато с мытьём пола в камере вполне справишься - хоть какая-то польза.

zabbal ★★★☆☆
()
Ответ на: комментарий от thesis

публично пожениться... это что-то новое...

как говорил к.прутков - тут могут быть варианты
- оба публично поженились
- один публично, другой втихую
- оба втихую

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

короче, не новость а пища для мозгов :о)

sunjob ★★★★★
()
Ответ на: комментарий от Ygor

серьёзная контора

Когда её, перед близтстью банкротства, будут дербанить Цурекбер и Микросвоп, вот тогда и отомрёт этот актив.

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

То есть это миллион строк в ДОВЕСОК к стороннему жс-движку?!

V8 не имеет стандартной библиотеки и модульной системы. Его прикручивают к браузеру, и добавляют dom api и модули, прикручивают к bun и добавляют функции работы с файлами, сетью, модули. К тому же такую махину нельзя просто взять и прикрутить.

(Извинитесь)

Да все уже привыкли, как вы привыкли ко всякой дичи в этом вашем сиплюсплюс. Между прочим, V8 на плюсах и bun на zig/rust это как раз из вашей вселенной и написано вашими ребятами, а не веб-программистами)

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от zabbal

Креативностью китайцев в плане того что можно считать едой :)

Креативность в еде — следствие голода. Программа создаётся небедными людьми в Сан-Франциско, поэтому пельмени не страшнее штатовского общепита.

question4 ★★★★★
()
Ответ на: комментарий от peregrine

Код будет лучше.

Это не ответ на мой вопрос «что именно будет лучше», поскольку «именно» подразумевает какой-то критерий, по которому будет лучше.

Даже ты с местными «разработчиками» сможете его поддерживать и коммитить туда.

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

shdown ★★
()
Последнее исправление: shdown (всего исправлений: 1)
Ответ на: комментарий от zabbal

Я так понимаю в штатах ты не был? :-D

Только в Великобритании. Сравнивал с Россией 1990-х. Местами плохо, но ничего сверхужасного.

question4 ★★★★★
()
Ответ на: комментарий от anonmyous

Более того, я прекрасно помню когда облака с контейнеризацией только выкатывались - были точь-в-точь такие же «рассуждения» от луддитов: да как эта бездушное поделие хипстеров, обмазавшихся смузи и ансиблом, сможет заменить настоящего матёрого админа с крошками в бороде и пятнами на штанах (коричневое сзади, жёлтое спереди)?!

По факту - отлично заменило (изрядно срезав зарплаты оставшимся) с единственным последствием: сайты стали реже ложиться.

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

zabbal ★★★☆☆
()
Ответ на: комментарий от zabbal

По факту - отлично заменило (изрядно срезав зарплаты оставшимся) с единственным последствием: сайты стали реже ложиться.

По факту - никак не заменили. Ни облака, ни анзибл, ни докер, ни k8s никак не отменили того факта что нужен человек, который всё это говнище настроит, запустит, заставит нормально работать. А то что это не ваш личный админ, а аутсорсер на работе в каком-то облаке - ничего не меняет.

Q-Master
()
Ответ на: комментарий от goingUp

ко всякой дичи в этом вашем сиплюсплюс.

Да(

А я думаю, что между БЯМ и цепепе есть сходство: корпорации дуреют с этой прикормки, а результат будет как обычно. Всё будет тормозить и лагать несусветно.

Вы видели приложенмя ЧатГпт? Что веб, что мобильное глюк на глюке( А их экстеншн для вскод грузил ядро (пришлось просить этот экстеншен пофиксить самоё себя (ЧСХ справился)).

BruteForce ★★★★
()
Ответ на: комментарий от cobold

пишет он код обычный. Не хуже кожаных. Проблемы скорее с тем чтобы донести что ты от него на самом деле хочешь

Я тут кстати вчера исправил. И всю ночь рефлексировал. Решил сюда скинуть код.

Задача была простая — убрать зависимость к libc. Дипсик заложил мину, которая не срабатывала пару месяцев.

static void my_zero(void *ptr, int size)
{
    char *p = (char *)ptr;
    for (int i = 0; i < size; i++)
        p[i] = 0;
}

static void my_wcscpy(wchar_t *dest, const wchar_t *src)
{
    while ((*dest++ = *src++))
        ;
}

static void my_wcsncpy(wchar_t *dest, const wchar_t *src, int n)
{
    int i = 0;
    while (i < n && *src)
    {
        dest[i] = src[i];
        i++;
    }
    if (i < n)
        dest[i] = L'\0';
}
sarumeister
()

Посмотрел я про этот зиг и блин почему все эти «убивцы» c и c++ такие всратые. Такое ощущение что основная цель этих языков не решить проблемы с а сделать fisting и suction программисту за небольшую цену в three hundred bucks.

ckotctvo
()
Ответ на: комментарий от LightDiver

Читал, это какой-то нейрослоп и на вопрос не отвечает.

vbr ★★★★★
()
Ответ на: комментарий от zabbal

Креативностью китайцев в плане того что можно считать едой :)

Я когда был в Китае, из необычного увидел только маринованные яйца. А так - просто курица, лапша и специи, вот и вся их еда. Никакой экзотики не увидел. Я, правда, был не в туристических местах, а где обычные работяги питаются.

А, не, экзотикой для меня стал способ подачи. Там был стол, в середине утопленный в стол казанок с кипящей водой. Они подают сырое тонко нарезанное мясо, ты его берёшь в щипцы и варишь прямо тут же, как тебе нравится, и съедаешь. Вот это было необычно. Но в целом как будто этим в повседневной жизни и не пользуются, это так, фишка типа.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от sarumeister

Three findings, one of which is a real memory-safety bug.

my_wcsncpy — out-of-bounds read (serious)

while (i < n && *src)

src is never incremented, so *src is always src[0]. The condition is therefore a constant for the whole loop: unless src is the empty string, it stays true and the loop runs the full n iterations regardless of where the terminator actually is.

For src = L"ab", n = 64, you read src[0..63] — 61 wide chars past the end of the array. Undefined behavior, and in practice a crash or an info leak into dest. Should be src[i].

Second issue in the same function: wcsncpy is specified to pad the remainder of dest with L'\0' up to n wide chars, not write a single terminator. As written you get neither behavior cleanly — no padding, and no guaranteed termination when the source is exactly n or longer. Standard-conforming version:

static void my_wcsncpy(wchar_t *dest, const wchar_t *src, size_t n)
{
    size_t i = 0;
    while (i < n && src[i]) {
        dest[i] = src[i];
        i++;
    }
    while (i < n)
        dest[i++] = L'\0';
}

If you actually wanted strlcpy semantics (always terminate, don’t pad), make that explicit with dest[n - 1] = L'\0' and a guard for n == 0 — but don’t leave it ambiguous, since the name promises wcsncpy.

my_zero — type and optimizer concerns

int size should be size_t. Callers almost always pass sizeof(x), and the implicit conversion silently breaks above INT_MAX; a negative value makes the function a no-op instead of trapping.

Two optimizer caveats depending on your context:

  • If this is meant for scrubbing keys or other secrets, the compiler is free to eliminate the stores entirely once the object is dead. You need volatile unsigned char * (or explicit_bzero / SecureZeroMemory).
  • If you’re building freestanding — and wchar_t alongside hand-rolled string functions suggests you might be — GCC and Clang both pattern-match this loop and can emit a call to memset. If my_zero is your memset, that’s infinite recursion. -ffreestanding alone doesn’t reliably prevent it; -fno-builtin-memset or -fno-tree-loop-distribute-patterns on that translation unit does.

my_wcscpy — logic is fine

while ((*dest++ = *src++)); is correct: the assignment yields the copied value, and testing it against zero works whether wchar_t is signed or unsigned. Only deviation is the signature — the real one returns wchar_t * (the original dest). Worth matching if these are meant to be drop-ins, since the return value is occasionally chained.

vbr ★★★★★
()
Ответ на: комментарий от ckotctvo

Посмотрел я про этот зиг и блин почему все эти «убивцы» c и c++ такие всратые. Такое ощущение что основная цель этих языков не решить проблемы с а сделать fisting и suction программисту за небольшую цену в three hundred bucks.

Что ты несешь? Зиг рвет С++ как тузик грелку по каждому аспекту и по всем аспектам вместе взятым. Это даже не касаясь вопроса бесшовного интеропа с Си и нативной компиляции последних стандартов modern C++.

sarumeister
()
Ответ на: комментарий от vbr

Зачем здесь твой нейрослоп?

ПС Собственно, реализации этих трех функций быть вообще не должно. В другом проекте все обошлось винапи-вариантами.

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 1)
Ответ на: комментарий от sarumeister

Почему он страшный то такой? Что мешает этим людям сделать красивый синтаксис не пытаясь на ровном месте подложить кучу программисту

ckotctvo
()
Ответ на: комментарий от ckotctvo

Почему он страшный то такой? Что мешает этим людям сделать красивый синтаксис не пытаясь на ровном месте подложить кучу программисту

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

sarumeister
()

На следующий день основатель Zig Эндрю Келли опубликовал резкий ответ.

Кисо обиделось.

А вообще из пол лимона в лимон строк полностью на автомате это мощно. Но там нужно смотреть, может 90% это тесты, тогда это нормально.

yvv1 ★★
()
Ответ на: комментарий от Gonzo

Вот что Rust животворящий делает!

Живо вытворяющий же... :))

Somebody ★★★★
()
Ответ на: комментарий от mamina_radost

Разраб стал частью Anthropic

Как-то раз стал раб частью Anthropic... :)

Somebody ★★★★
()
Ответ на: комментарий от water_closed

когда котикам нечего делать… эээ, но это, наверное, на лоре будет неприлично показывать

unclestephen ★★★★★
() автор топика
Ответ на: комментарий от shdown

Это не ответ на мой вопрос

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

Это будет делать сложнее

А ты много туда накоммитил? И нет, это не будет сложнее.

peregrine ★★★★★
()
Ответ на: комментарий от sarumeister

Открываешь сорцы в std — и глаз радуется

Если же правый глаз твой соблазняет тебя, вырви его и брось от себя, ибо лучше для тебя, чтобы погиб один из членов твоих, а не все тело твое было ввержено в геенну.

Что вас нейрослоперов так влечет к языкам с сатанинским синтаксисом то

ckotctvo
()
Ответ на: комментарий от ckotctvo

Что вас нейрослоперов так влечет к языкам с сатанинским синтаксисом то

Синтакс сатанинский в расте с его лайфтаймами, дженериками и трейтами.

В Си с его

int (*(*(*(*f[])(void))(int, char *(*)(double)))[42])(long);

В С++ сатанинский синтаксис, вот из недавнего. Даже в макрос пришлось заворачивать, чтобы исходники не портить: #define LIFT(F) [](auto&&… xs) constexpr noexcept(noexcept(F(std::forward<decltype(xs)>(xs)…))) -> decltype(auto) { return F(std::forward<decltype(xs)>(xs)…); }

В зиге синтаксис добрый, логичный и понятный. Он там еще и изначально разрабатывался под LL(k) парсеры (context-free, if you know what I mean).

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.