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)
Ответ на: комментарий от LightDiver

Давай в код ядра линукса, хромиума, да даже Inkscape нырнём. Каша там, а все костыли проектирования просто не дают каше превратиться в макаронную фабрику. Вылизанного кода (на самом деле сделанного для удобного понимания кожаными) практически нет, потому что писать его долго, сложно и дорого. А рабочий код нужен уже вчера. Может ядро GNU Hurd хорошее, не знаю, не смотрел. Его долго, медленно пишут и именно что для себя, т.е. вылизывают.

Даже давай вот как поступим. Ты выдернешь любой фрагмент кода, запостишь его на ЛОР (из любого реального проекта), а я попробую обосрать его, скажу что надо было лучше сделать, если код правда для людей писался. Только чтоб он какую-то конкретную вещь делал, а не сферического коня в вакууме.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)

Ирландская пословица: «Если два соседа дерутся, значит накануне у одного из них ночевал англичанин»
Ирландская пословица (IT Edition): «Если два программера дерутся, значит накануне у одного из них был установлен Rust»

По факту расписали в треде, bun 1.4+ можно считать теперь мёртвым куском нечитаемого кода, которое после первых кайфариков уйдет по стопам всего слопа: очень быстро перестанет обновляться (version bump не считается) и повиснет на шее у антропиков. Учитывая, что пузырь ЫЫ уже начинает лопаться (привет, доткомы) - ну, R.I.P. Сладенький Принц

DzenPython
()

Ненужно ненужно с ненужно по поводу ненужно ненужно с ненужно на ненужно.

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

В случае bun я на 100 процентов уверен, что теперь ни люди, ни ИИ не смогут дальше развивать полученный код на Rust. Добавление любой новой фичи с помощью ИИ опять потребует over 150к баксов на токены. Тех долг между тем растет по экспоненте, и никто из разработчиков не захочет заниматься этим Rust портом.

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

Нет, ну должны же быть какие-то рамки.

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

Смотря какие фичи. Иногда в реальных проектах приходится переписывать большую часть кодовой базы, рефакторить и т д. Можно рассмотреть аналогию с компиляцией в машинный код. Так же берем на входе спецификацию на языке более высокого уровня и так же получаем программу на машинном языке (в данном случае Rust). Человеку существенно модифицировать эту программу, это примерно как пытаться добавить новую функциональность в готовый бинарник после C компилятора. Это также довольно трудозатратно для ИИ с конечным контекстом, который в легкую заполнится на такой задаче. Да это и бессмысленно, как минимум в смысле энергозатрат, на каждую модификацию заново строить в памяти модель проекта.

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

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

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

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

mamina_radost
()
Последнее исправление: mamina_radost (всего исправлений: 1)

проблемы Bun возникли не из-за модели памяти Zig

За насилие над разработчиком в виде ручного управления памяти нужно платить в два раза больше. Иначе это просто гей-БДСМ клуб.

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

Ну понятно, что все затеяно ради продвижения Anthropic. Но для средней компании (клиента антропиков), рассматривающей подобный сценарий создания или переписывания проектов, лимит токенов никто не отменит. В случае с Bun мне больше жалко Zig Foundation, которые делают нужное дело и при этом без серьезной финансовой поддержки.

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

Да, вы правы, рули нужно было проектировать так, чтобы можно было всплыть

(смайлик)(смайлик) В версии 2.0 теперь нет утечек воздуха - сейчас при погружении весь объём уже на поверхности заполняется водой, и утечек никаких нет

Да, вы правы, для реактора требуется делать контуры защиты. Но чтобы спасти экипаж нужно использовать святой подорожник и ослиную [Источник: church.org] и дискамибомбулятор [Источник: whitehouse.gov/citate]. А кто умер от лучевой болезни, тот еретик [Источник: islam.kaaba.sa], грешник [Источник: father-rimsky.ru], имеет восемь ног: две передние, две задние, две левые и две правые [Источник: reddit.com], и коммунист [Источник: maga.us]

Да, вы правы, убивать весь экипаж выхлопом от дизеля было не нужно, Однако если убить весь экипаж, то никто не будет мешать патрулировать подводные антенны на дне

DzenPython
()
Последнее исправление: DzenPython (всего исправлений: 1)

Отличная новость. Ненужно переписали с ненужно на ненужно, после чего ненужно с ненужно переругались и сделали ненужнй форк, где вернули ненужно.

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

Вы вообще представляете что такое миллион строк кода? Еще парочка таких переносов и оно вполне сравнится с линуксом, например.

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

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

да, вы правы, я ошибся, аппендицит находится справа, а не слева, хотите что бы я переделал операцию по удалению с новыми вводными?

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

…после чего отрезает пациенту голову, как самый простой и быстрый способ «сделать правильно».

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

Да, вы правы, не надо было клеить голову на «Момент» на обезглавленное тело, затем распинать труп пациента на кресте, держать его на солнце семь суток, а затем класть в пещеру, обмотав простынёй. Однако есть пул источников, описывающих таким образов воскрешение из мёртвых [Источник: <Евангелие и пул из сотни тысяч его пересказов и толкований>] и это было необходимо, чтобы повторить операцию.

DzenPython
()

JS платформа переписана ИИшкой с одного убийцы сишки на другого. Ребята молодцы, это прямо «вечный» рекорд. Можно ли достичь большего уровня ненужности?

buddhist ★★★★★
()
Ответ на: комментарий от splinter
Хирург с ассистентом делают обход отделения. У ассистента в руках топор.
-Так, этому больному ампутировать левую руку!
``Хрясь!`` - блестнул топор ассистента.
-А этому больному ампутировать правую ногу!
``Хрясь!``
-А этому больному - левую ногу!
``Хрясь!``
-Я же сказал - НОГУ!
``Хрясь!``
-Я же сказал - ЛЕВУЮ!
``Хрясь!``

Анекдоту больше лет, чем мне - точно. Как мы видим, естественные нейросети руинили не хуже, когда это еще не было мейнсримом.

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

Легко. (сразу с первого и даже не пойду дальше самой первой функции, вся дурь уже там начинается).

static mp_limb_t mpn_mul_fft_internal (mp_ptr, mp_size_t, int, mp_ptr *,
				       mp_ptr *, mp_ptr, mp_ptr, mp_size_t,
				       mp_size_t, mp_size_t, int **, mp_ptr, int);

С названиями беда. Требуется погружение в предметную область, чтоб понять что же это за mp такие. Вероятно (из того что проект gmp это всё же сокращение от multi-precision, что в свою очередь и хорошо и плохо. Хорошо потому что понятно, плохо потому что бессмысленно. Давай развернём что тут написано и переведём на русский для подчёркивания уровня безумия к которому все привыкли и даже не замечают. static это понятно, к нему претензий нет.

статично многократная_точность_конечность многократная_точность_натуральное_умножение_быстрое_преобразование_фурье_внутренняя_функция (многократная_точность_указатель, многократная_точность_размер_типа, целое, многократная_точность_указатель *, многократная_точность_указатель, многократная_точность_указатель, многократная_точность_размер_типа, многократная_точность_размер_типа, многократная_точность_размер_типа, целое **, многократная_точность_указатель, целое)

Эпичный обосрамс начинается с limb. Авторы упороты и решили поиграть в метафоры (словно я на уроке английской литературы). Всё дело в том, что digits это цифры, а человек по их мнению считает пальцами, так как одно из значений слова digit это палец. Такой метафорой они решили воспользоваться потому, что конечность включает в себя пальцы, и вместо более крупных блоков (так называемых машинных слов, они обозвали это конечностями, я не знаю шизофрения это или что-то ещё, но явно требуется осмотр у профильного специалиста). Ладно, едем дальше. Тут по сути оставили только типы, выкинув осознанные имена. Ладно, пусть так. Внутренняя кухня, каждый пляшет так как хочет, но следующая же функция не объявлена как internal в названии и там точно такие-же наименования. Значит либо авторы не следуют своим же собственным соглашениям в наименовании функций, либо не уважают своих пользователей. Я склонен думать что это первое и вообще никаких соглашений по наименованию у них нет. Кроме того, я считаю, что комментарий вида

/*****************************************************************************/

менее аккуратен, чем комментарий вида

//=============================================================================

из-за / на конце, это чисто разделительная линия, ей не нужно быть многострочным комментарием

Дальше, все эти int i, j, K; это плохо, даже в математическом коде. Так делают от лени. Ну или не мешают эти переменные со всякими GMP_NUMB_BITS в одной формуле. Начал писать буквами, так и пиши ими. Не начал, будь добр писать counter и так далее (можно оставить i, j для вложенных счётчиков, но K уже быть не должно). Кроме того комментарии не однородны. Где-то пишется от третьего лица про код, где-то от we и так далее. Это напрягает голову читающего. Более того, doxygen-у уже 28 лет, можно было бы начать им пользоваться. Закомментированные фрагменты кода это отдельная песня. Я не хочу разбираться где там пояснения к коду из-за оптимизаций, а где просто мёртвый код остался висеть. Но так тоже быть не должно.

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

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

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

А что именно будет лучше, если разработчики будет следовать вашим советам? Зачем нужен «уровня безумия к которому все привыкли и даже не замечают»? Вы и сам понимаете, что это будет сложнее читать.

Для кого именно все эти длинные названия сущеностей и обширные комментарии?

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

Я не в курсе, а 4 года назад уже можно было вайбкодить?

И 40 лет назад можно было - просто тогда этим занимались естественные нейронки, почему-то считающие себя программистами. Они и сейчас никуда не делись - у них под каждой новостью про Rust пригорает например ;)

zabbal ★★★☆☆
()

Читал ещё в оригинале свежаком.

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

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

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

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

Сейчас врядли понимает хоть кто то.

То что ты даже чтение кода не осиливаешь ещё не значит что у остальных такие же проблемы.

Контекстное окно ИИ не бесконечно

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

В итоге и человек не может понять крупный проект

Ага, а линукс пишут инопланетяне?

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

ИИшка пишет обфусцированный код

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

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

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

В каждом пересказе меняются акценты. Даже здесь.

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

Лучший комментарий, что видел по теме, ссылается на лор вахи: спор между Радикалом и Пуристом.

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

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

почему в два раза? На порядок.
Утверждение «в два раза» было бы верным если бы надо было платить ИИ.
Для людей надо брать десятичный порядок (люди в этой системе счисления работают).
То есть людям за переход на ручное управление памятью платить надо в десять раз больше.

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

Главный вопрос: оно работает?

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

vbr ★★★★★
()

Очень хорошо, что они решились. Можно будет посмотреть с какими проблемами они будут сталкиваться. А свалить с zig правильное решение. Ручное прокидывание аллокатора во все задницы кода - это полнейшая наркомания.

ox55ff ★★★★★
()

компания Oven перечисляла Zig Software Foundation около 60 тысяч долларов в год, но после покупки Bun компанией Anthropic выплаты прекратились

так все дело в деньгах

ckotctvo
()

Мне тут подумалось что вся эта история ещё может быть косвенной рекламой zig: типа в bun и rust засели нейрослоперы, фу на них, зато смотрите zig чист в этом плане.

Но думаю это не было целью, целью был всё-таки нелепый пиар клаудэ о том как они успешно онейрослопливают большие проекты.

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

откуда взяли код на zig

«Bun started as a line-for-line port of esbuild’s JavaScript & TypeScript transpiler from Go to Zig.»

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

разве «примерно так» не «примерно у всех»? и это еще не самый худший вариант!

добавлю отсебЯтину: в свой код стараюсь вставить максимально полные комментарии/описание. спорить не буду, для кого-то это будет считаться «ваще отстоем», но для себя я «понял» что это наиболее оптимально.
и так, думаю, у большинства + корп.стиль, личные предпочтения, типа «пробел-табуляция»... и поскакал иван царевич... вариантов целая вселенная :о)

имхо, проблема, как и везде, именно в хороших/ответственных программистах и отношении в коллективе.
от этого зависит почти всё :о) ... ну, или зависело, до недавнего времени. имхо

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

А покажи пример непонятного кода написанного иишкой. Можно прям сабжевый проект использовать для иллюстрации

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

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

Это любой код, который раздут до такого состояния, что чтобы его прочитать, нужны годы. А еще нужно понять. Когда тебе вместо 3 строк дают 50 - это нечитаемый код. Потому что тебе нужно в 20 раз больше, просто чтобы в него вчитаться. Это время, силы, ты за это время написал бы 10 подобных кодов вручную.

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

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

любой код, который раздут до такого состояния, что чтобы его прочитать, нужны годы

Ну то есть все что сложнее хелловорлда? Линукс, браузеры, компиляторы - всё в мусор?

cobold ★★★★★
()
Ответ на: комментарий от cobold
— Какая ваша главная слабость?
— Я правильно интерпретирую семантику вопроса, но полностью игнорирую его суть.
— Не могли бы вы привести пример?
— Мог бы.

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

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

LightDiver ★★★★★
()

Представлены Buz и Cruller, форки JavaScript-платформы Bun, продолжающие развитие на языке Zig:

После объявления о переводе JavaScript-платформы Bun на язык Rust при помощи AI и задействования Rust в кодовой базе, на основе которой формируется ветка Bun 1.4, несколько энтузиастов объявили о создании форков платформы, продолжающих развитие с использованием языка Zig.

Проект Buz (github.com) подхватил разработку старой кодовой базы Bun с последнего коммита перед переходом на Rust. Среди особенностей форка заявлено задействование новых возможностей языка Zig и переход на сборочный инструментарий Zig для реализации поддержки очень быстрых инкрементальных пересборок платформы, выполняемых менее чем за секунду. Целью Buz является возможность использования в качестве прозрачной замены Bun и прохождение всех новых тестов, развиваемых для версии Bun на Rust. Из проводимых проектом работ также отмечается модернизация некоторых компонентов с использованием штатной стандартной библиотеки Zig и проведение чистки старой кодовой базы от неактуального кода или кода, созданного через AI, для уменьшения технического долга (уже удалено около 11 тысяч строк кода).

Автор форка является противником применения AI, но для разбора уже имеющегося в старой кодовой базе Bun кода, созданного при помощи AI, планируется привлечь AI-инструменты, так как по его мнению вручную разобрать и привести в порядок около 600 тысяч строк «AI-слопа» нереально. До приведения кодовой базы в вид, пригодный для ручной разработки, решено не принимать pull-запросы от людей. При этом AI рассматривается как временный инструмент для чистки кодовой базы и применения идиоматичного языка Zig, чтобы в будущем поддерживать проект без помощи AI.

Второй форк основан на коде Bun 1.3.14 (последний выпуск на Zig ) и опубликован под именем Cruller. Форк ограничен разработкой только Bun Runtime для запуска готовых JavaScript-приложений на сервере и сосредоточен на переводе кода на использование языка Zig 0.16 вместо Zig 0.15. Расширенные возможности Bun, такие как управление пакетами, интеграция с TypeScript, N-API, SQL-клиенты, shell и система тестов, не охватываются форком.

Cruller переведён на новую систему сборку и использует прослойки для API, которые изменились между версиями Zig 0.15 и 0.16. Из специфичных возможностей отмечается модуль для встраивания сгенерированного кода, позволяющий создавать автономные сборки, не требующие подгрузки JavaScript-файлов во время выполнения. По сравнению с Bun 1.3.14 размен исполняемого файла Cruller уменьшен с 88 до 73 МБ (-18%), производительность нового Runtime осталась примерно на том же уровне (для сравнения, размер исполняемого файла Bun на Rust сократился на 20%, а производительность увеличилась на 2-5%).

При разработке Cruller AI-ассистенты не применяются для генерации кода, а используются только как вспомогательные инструменты для помощи в миграции на Zig 0.16, отладки и написании тестов. Архитектурные решения, рецензирование кода и проверку результатов осуществляет человек.

🍿🍿🍿🍿🍿

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

Вы только что привели пример очень краткого, корректного, но бесполезного ответа. Не всегда 20 строк написанных самостоятельно «лучше» 380. Критерий «лучности» ill defined.

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