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)
Ответ на: комментарий от VIT
function SearchAndSendToGuild(str, array)
    if not str or not array then return end
    for i=1, #array do
        if string.find(array[i]:lower(), str:lower()) then
            SendChatMessage(array[i], "GUILD")
        end
    end
end
function SearchAndSendToGuild(searchStr, array)
    if SendChatMessage then
        if not searchStr or searchStr == "" then
            print("Ошибка: пустая подстрока для поиска")
            return
        end
        
        if not array or type(array) ~= "table" then
            print("Ошибка: неверный массив")
            return
        end
        
        local found = {}
        local pattern = ".*" .. searchStr:gsub("%W", "%%%1") .. ".*"
        
        for i, item in ipairs(array) do
            if type(item) == "string" then
                if string.match(string.lower(item), string.lower(pattern)) then
                    table.insert(found, item)
                end
            end
        end
        
        if #found == 0 then
            SendChatMessage("По запросу '" .. searchStr .. "' ничего не найдено.", "GUILD")
        else
            SendChatMessage("Результаты поиска '" .. searchStr .. "' (" .. #found .. "):", "GUILD")
            for i, item in ipairs(found) do
                if i <= 10 then
                    SendChatMessage(i .. ". " .. item, "GUILD")
                end
            end
            if #found > 10 then
                SendChatMessage("... и еще " .. (#found - 10) .. " совпадений", "GUILD")
            end
        end
    else
        print("Ошибка: функция SendChatMessage не найдена")
    end
end

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

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

Когда я спросил одного инженера-программиста, а зачем вы изобретаете маловероятные и иногда даже глупые проверки он мне ответил «меня так учили».

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

С одной стороны, проверки нужны. Я сначала написал код на 46 тысяч строк, который просто срал ошибками на nil бесконечно. Каждый день приходилось несколько раз лазить по коду и делать проверки над проверками, затем обмазывать их сверху проверками. Потому что изначально криво было все сделано.

Код написанный ИИшками частично решает эти проблемы, я не против проверок, но когда видишь 380 строк так, где хватает 20 - я тут уже начинаю материться и пишу вручную.

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

Ну ты представь, каждая мелкая функция по 200-500 строк. Чуть простейшая фунацаионалность, 3-4 тыщи строк. На простейшие задачи.

А теперь ключевое. У тебя почти 600 тысяч строк кода, как выше всетаки подтвердили - частично навайбкоденого (цитирую: «так как по его мнению вручную разобрать и привести в порядок около 600 тысяч строк «AI-слопа» нереально»).

Ты из них делаешь больше ляма строк тоже навайбкоденого. Куда это? Ты будешь читать больше ляма этой развесистой херни? Кто будет? Сколько будет?

Причем их правильно учили. Но иногда надо разум включать. Вот почему в моем примере есть лишние проверки? Да потому что если при отсутствии функции просто не будет работать весь сервер, эту проверку на юзерском уровне делать бессмысленно.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 3)
Ответ на: комментарий от Gonzo

Это характерная черта сообщества Rust, почему с ним не связываюсь.

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

Я с этим полностью согласен, раздувание кода без причины имеет только отрицательный эффект. Я только говорю, что этот приём, часто идущий в совокупности с другими приёмами «индусского кода», применялся задолго до кодогенерации LLM. Причём я рассказываю реальный случай из своей жизни - тот человек просто не понимал, что здесь такого, ну проверил он, что вывод содержит больше 10 значений и написал ещё 20 строк вывода покрасивее. Ведь красиво же!

Потом я стал понимать его ситуацию чуть больше. Главное в том, что он даже не планирует поддерживать этот код. Вот эта мысль «что легче поддерживать, 20 строк или 380?» в его голове полностью отсутствует. Когда я спросил «а как ты будешь это поддерживать?» он меня просто не понимает. Что значит поддерживать? Я завтра вообще этот код уже не увижу.

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

Да, добавлю ещё, дело здесь не в национальности, образовании, или опыте программиста. Дело целиком в политике компании. Если компания на уровне менеджмента поддерживает и поощряет такую практику, программисты быстро адаптируются. Что касается LLM, то как и любой инструмент, его можно использовать для генерации краткого кода с минимумом проверок.

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

Я попытался тут создать код краткий. Вышло 3200 строк. Ладно, подумал я - человек я разумный или право имею? И пошел оптимизировать, подсказывать. Через два часа оптимизации, мы выкинули кучу всякого с сохранением фунациональности и теперь у меня 4800 строк кода…

Как думаешь, оставляю или попробовать еще раз?

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

В целом я еще в году этак в 2020-2021 автозаполнял кодом в Идее. Причем оно именно автозаполняло, то есть угадывало, что я хочу следующим написать.

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

Ещё пробовать. Может получится выкинуть всякого до 5600 строк. А в чём цель то этой деятельности, ну кроме желания написать красиво, чтобы самому нравилось? Или как раз это и есть цель?

VIT ★★★
()

Короче говоря NodeJS будет жить еще долго xD

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

https://ns.fiber-gate.ru/uploads/images/img_1785040612471_94bff7e7.jpg

https://ns.fiber-gate.ru/uploads/images/img_1785063162211_e8bfeb6a.jpg

Да простейшая задача. В игре если игрок стоит на месте, появляется паучок и начинает плести паутину вокруг элементов интерфейса. И сжирает их иногда. Ничего сложного.

Но представь: нужно расширить код. Прокачка пачука, скрещивание паучков между юзерами, битвы паучков с анимациями итд. Допустим сделал я эти клятые 5600 строк кода. Логика размазана между функциями. Мне надо допиливать, дописывать, дополнять. Переписывать старое. Начну допиливать новые фичи - это еще на 3-4 тыщи строк. И вот у меня уже дестяка. И вот уже бесплатные модели разом их не могут. А я весь код уже не помню. Все, приплыли.

Мне проще написать сотни в 3-4 строк вручную подобную логику. Потратить на это часов 5, но потом будет проще.

Смысл в том, что это код не одноразовый как раз - это задача на годы вперед. По сути мини-онлайновая игра в онлайновой игре. И чем больше я пользуюсь ИИшками, тем больше дергается глаз от того на что они способны.

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

И тут такая новость: «Навайбкодили лям строк, глядите какие мы молодцы!». А у меня один мат в ответ, но нельзя. Ну мы же приличные люди всетаки.

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

Смысл в том, что это код не одноразовый как раз - это задача на годы вперед. По сути мини-онлайновая игра в онлайновой игре.

То есть хобби.

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

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

Значит вы не поняли самого главного - ИИ программирование не является технологией хобби проектов. Это технология промышленного производства.

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

Значит вы не поняли самого главного - ИИ программирование не является технологией хобби проектов. Это технология промышленного производства.

Вот именно это меня и беспокоит. Я в рамках своего гобби могу наговнокодить что то и это никому особо вреда не принесет. Приносит даже пользу кое как. А вот в рамках производства это ведет к краху в перспективе, что может и меня задеть.

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

Мне проще написать сотни в 3-4 строк вручную подобную логику. Потратить на это часов 5, но потом будет проще.

Это тоже подход хобби проектов.

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

А разве строгая логика создания кода и его читаемость для совместной разработки - не являются приоритетами для производства?

Я не думаю, что достаточно наговнячить как придется, а после меня хоть трава не расти.

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

Да! Это проблема. Мы, по-видимому вы также как и я, вкладываем в каждую строчку кода смысл, душу, желание написать хорошо, желание написать один раз и не переделывать. Поэтому перед написанием мы посидим и подумаем. Причём не важно, хобби - не хобби, мы по другому уже не умеем. А если по честному, то и не хотим. Мы не планируем писать индусский код. Мы не желаем писать индусский код. После всего, что уже написано, мы просто не умеем писать индусский код.

Это противоречит индустрии программирования. Наша работа слишком дорого и долго обходится индустрии программирования. Поэтому индустрия идёт другим путём. Конечно, не вся индустрия. Кому-то удаётся оставаться на плаву.

А теперь посмотрим на проекты, которые мы обсуждаем здесь. Кто их разрабатывает? Типичные представители индустрии программирования. Следует ли удивляться, что они используют приемы программирования, принятые в их профессиональной среде?

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

А разве строгая логика создания кода и его читаемость для совместной разработки - не являются приоритетами для производства?

Очевидно, что нет. Сейчас, по-видимому, приоритетами является скорость разработки.

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

Я не думаю, что достаточно наговнячить как придется, а после меня хоть трава не расти.

Я тоже так не думаю. Но это ничего не меняет.

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

функциональность которого можно реализовать в десять-тридцать раз меньшим количеством кода

Что за юродство? Как 2 раза превратилось в 10-30 раз? Покажи пример этого феерически раздутого кода

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

Спасибо, новость от unclestephen как обычно ввела в заблуждение.

Теперь в принципе возмущений и непонятнок нету. Zig сами быканули и встали в позу, а это переписывание показательная акция возможностей. В таком контесте весьма интересное.

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

Дипсику и алисе я бы тоже код не дал писать.

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

и никто из разработчиков не захочет заниматься этим Rust портом

Ну нельзя настолько откровенно то тупить - этот порт буквально сделан разработчиками проекта. И сделан как раз потому что им захотелось этим заниматься. Да, они забыли спросить недоумков что и как им делать, но это известный источник баттхёрта вокруг FOSS проектов - ничего не поделаешь.

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

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

Если видишь полоумного луддита - с вероятность 100% он не бельмеса не смыслит в технологии, которую столь яростно обсирает: потому что даже не пытался в ней разобраться - видимо заранее предполагая что всё-равно не осилит.

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

А это уже называется не умеем мы вайбкодить. Нужно как раз те самые экстремальные ограничения и проверки. Просто с разработкой на ИИ, надо считать что у тебя есть большая-большая команда джунов-макак. И соответственно требовать с ИИ ровно того же самого что и с толпы джунов или ЛОР-овцев. Там в соседней теме как раз автора SOLID осуждают за это самое.

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

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

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

лимит токенов никто не отменит

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

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

Я вот уже неделю обдумываю этот подход: ограничения, строго выверенные промты, скиллы.

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

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

Можно ли достичь большего уровня ненужности?

Легко - в твоём случае достаточно просто найти зеркало.

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

Переписывал код на 50к строк, вышло $200

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

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

покажи пример

Это любой код

Пха-ха-ха, даже это не осилил?! А как дышал, как дышал :-D :-D :-D

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

Нет конечно. Потому что ИИ не замена одного тебя на проекте, а замена целой команды из 100500 разработчиков. Целого отдела. А то что у тебя теперь голова стала болеть как у техдира/руководителя проекта это ожидаемо. Потому что тебе теперь надо думать не о том, как код писать, а о том, как организовать обезьянок (теперь железных) чтоб они качественно код писали.

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

Если не развивать их и не обучать до полного понимания происходящего, это все не имеет смысла. Более точные шаблоны и алгоритмы гораздо эффективнее будут в данном случае. Проще сделать готовые фреймворки и инструменты для языков программирования.

В этом случае хотя бы рандома не будет.

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

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

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 5)
Ответ на: комментарий от dataman

является противником применения AI

планируется привлечь AI-инструменты

AI-ассистенты не применяются

AI-ассистенты… используются только как вспомогательные инструменты

Это всё-равно что читать greentext c 4chan где автор в первых строках говорит I’m straight - сразу понятно что дальше последует лютейшая гомосятина :-D :-D :-D

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

этот приём, часто идущий в совокупности с другими приёмами «индусского кода», применялся задолго до кодогенерации LLM

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

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

Я честно говоря так и не понял, зачем они это сделали. Если в качестве демонстрации возможностей LLM, то да, внушает.

Хотя я вообще не понимаю смысла существования этих бунов и денов. Есть же node, всё остальное это как бы лишнее…

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

Я честно говоря так и не понял, зачем они это сделали. Если в качестве демонстрации возможностей LLM, то да, внушает.

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

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

Нет.

что нет? это ответ на

разве «примерно так» не «примерно у всех»?

ну дак это «ваша практика» и дай бог!
а вот я как ни залезу в «чужой код», так глаза сами плачут и сами слезы вытирают... :о)

У всех обычно ещё хуже.

ну вот так ... да, примерно...

Но это не повод считать что это хорошо.

да кто-же спорит?!

в итоге, мы об одном и том-же, но разными словами?!!! :о)

sunjob ★★★★★
()

Было 500000 строк, стало 1000000? Неудивительно, что появились регрессии. Сколько багов ещё будет сгенерено, у-х-ху!

BruteForce ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.