OpenAI переписує Codex з TypeScript на Rust

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Rust дібрався й до OpenAI. В компанії вирішили переписати свій інструмент для роботи з кодом, який досі працював на TypeScript і Node.js.

За словами мейнтейнера проєкту Фуада Матіна, основна мета — зробити Codex продуктивнішим, безпечнішим і простішим у використанні, зокрема уникнувши залежності від Node.js, яка іноді створює технічні обмеження для користувачів.

Хоча поточна версія була створена досить швидко завдяки React і TypeScript, команда бачить чотири ключові переваги переходу на Rust:

  • Просте встановлення. Новий Codex не потребує встановлення Node.js, що спростить старт роботи для багатьох.
  • Краща ізоляція. Rust-версія одразу передбачає запуск у захищеному середовищі: sandbox-exec на macOS і Landlock на Linux.
  • Вища продуктивність. Менше споживання пам’яті, відсутність збирача сміття і загалом швидша робота.
  • Підтримка MCP. Codex CLI на Rust зможе бути як клієнтом, так і сервером Model Context Protocol, що відкриває нові можливості для інтеграцій.

TypeScript-версія тим часом залишатиметься активною — принаймні до того моменту, коли Rust-реалізація наздожене її за функціональністю.

Так, Rust вимагає трохи більше зусиль від розробників, якщо зрівнювати з JavaScript чи Python, він складніший у роботі. Але ефективність, контроль і розширюваність, які він дає, для OpenAI виявились вагомішими. До того ж Codex CLI на Rust усе ще можна буде доповнювати модулями на інших мовах — зокрема JavaScript і Python.

Нагадаю, що раніше серед розробників Linux точилися суперечки щодо інтеграції Rust до ядра системи. Однак згодом Лінус Торвальдс підтримав цю ідею, фактично поставивши остаточну крапку в дискусії, а ментейнер, який був проти цього — покинув команду.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Що цікаво там команда, а не самим AI портували. Пригадався фільм з Челінтано, де по результатам змагання із машиною яка чавить виноград був куплений електронний калькулятор.
Про трохи більше зусиль посміхнуло, там зусиль навіть трохи більше за С++, бо більш сурові перевірки і компілятор постійно з тобою бьється купою обмежень, як колись писав Саттер потставляє колеса жля дитячого велосипеда всім включно із велогонщіками, проти Python чи TypeScipt зусиль суттєво більше буде.

Так в штатах грозятся запретить в гос органах не сейф языки и с++ больше не канает. Вот раст и всплыл

Виглядає як спроба реанімації практики обкомів компартії вказувати колгоспам коли що сіяти і коли що жати.

C++, починаючи із редакції стандарту C++ 2011 року, дозволяє за допомогою smart pointers писати memory safe код всім, кому це потрібно.

Виглядає як спроба реанімації практики обкомів компартії вказувати колгоспам коли що сіяти і коли що жати.

Еще обком говорит, что нельзя пользоваться краской со свинцом.

MS Windows майже повністю написано на тотально unsafe the C programming language.

Те саме стосується Linux kernel, поверх якого працює Android.

То як стосовно заборони на використання OS, написаних на unsafe мовах, у держ. органах США?

MS Windows майже повністю написано на тотально unsafe the C programming language.

www.thurrott.com/...​he-windows-kernel-in-rust

Те саме стосується Linux kernel

rust-for-linux.com

поверх якого працює Android.

www.zdnet.com/...​y-safety-vulnerabilities

Колись операційні системи писали на Assembly languages.

Але це було складно, дорого та довго, адже Assembly is a human-readable machine code with CPU-specific direct hardware mapping with telling the machine exactly what to do, instruction by instruction.

Пізніше стали писати операційні системи на C. Бо на відміну від Assembly C is about describing what you want to be done in a more human-friendly way, and letting the compiler do the hard work of translating higher-level logic into the specific assembly instructions for the target machine.

Через те, що С дозволяє при розробці OS оперувати такими категоріями як variables, functions, data types, pointers, control structures, з’явилась можливість створення більш функціональних та зручних OS, порівняно з OS, які можна було розробити на Assembly, оперуючи такими категоріями як registers, memory addresses, opcodes.

Хоч виклики функцій та control flow оператори є набагато ефективнішими засобами написання коду ніж jump-и між блоками асемблерного коду, подальше нарощування функціональності та зручності OS стає невиправдано дорогим за допомогою інструментарію, який може забезпечити C. Тому OS вендори намагаються знайти більш високорівневу альтернативу C.

Вже є на часі потреба при розробці OS перейти від викликів функцій, відокремлених від даних, що обробляються, до програмування взаємодії об’єктів, що моделюють сутності та процеси реального світу.

В сучасних умовах найкращим вибором для цього є RAII-based мови програмування.

Сьогодні маятник вибору хитнуло у бік рівня memory safety і thread safety, що здатен забезпечити Rust borrow checker.

Але невідомо що буде коли std::executor стане частиною C++ 26 і, додасть певний рівень thread safety, окрім вже існуючого рівня memory safety, що забезпечується smart pointers.

Трудова діяльність сучасної людини триває в середньому 42 роки. І дуже бажано як-найбільшу частину цього часу витратити на мейнстрімні технології, а не ті, що можуть бути не більше ніж донорами ідей для більш вдалих рішень.

Написано українцем для українців. Щоб нашому роду не було переводу.

Трудова діяльність сучасної людини триває в середньому 42 роки. І дуже бажано як-найбільшу частину цього часу витратити на мейнстрімні технології, а не ті, що можуть бути не більше ніж донорами ідей для більш вдалих рішень.

жизнь надо прожить так, чтобы нє было больно за бєсцєльно прожытыє годы, чтобы нє жог позор ... © П.Корчагин

бєсцєльно прожытыє годы ...

... очікуючи поки збереться раст-прожект

зате як збереться, то не потрібно буде роками дебажити

з̶а̶т̶е̶ ̶я̶к̶ ̶з̶б̶е̶р̶е̶т̶ь̶с̶я̶ якщо збереться ...

... з вчорашнім кул компайлером той код написаний під last night версію, і якщо не витратять ті роки на боротьбу з borrow checker

з ним не боротися потрібно, а кооперуватися.
нічні зборки то для хіпстерів

Складність та незручність використання borrow checker, свідчить про те, що це — явний over-engineering і тупикова технологія.

Safety, рівно як і Security є похідними від більш загального Correctness.

Враховуючи гнучкість та відкритість C++ by design, C++ community невдовзі обов’язково створить zero-overhead абстракцію, або декілька таких абстракцій, що стануть ефективнішою альтернативою ніж borrow checker.

яка вартість розробки і підтримки на вашому С++ 2011 року?

якщо в контексті топіка — то спершу треба порівняти відповідну вартість для ts і rust (для бази подальших порівнянь — яка та вартість виходить у ts, у rust ?).

І як на вартість розробки/підтримки впливала би наявність стандартизації — в яку сторону — збільшення чи зменшення того

C++ — це лише інструмент, який, як і будь-який інший інструмент, має власні межі доцільності використання.

Так TS и так типа безопасный. С него-то зачем уплывать?

А животноводство?

Servo:
...
Development of Servo began at the Mozilla Corporation in 2012.
...
In August 2020, Mozilla laid off the Servo team.
...
In February 2024, at FOSDEM 2024, the Servo Project team outlined their plans for a ’reboot’ of Servo.

Оскільки Servo Rust спільнота вважає своїм найуспішнішим проєктом, то мабуть немає причин для не повторення успіху у випадку і з Codex та Linux Kernel.

Не дарма Rust спільнота ще й досі вважає, що їх мова не доросла до ISO стандартизації.

Не дарма Rust спільнота ще й досі вважає, що їх мова не доросла до ISO стандартизації.

SO-стандарти мають сенс, коли є конкуренція реалізацій. Коли реалізація одна, стандартизація — це передчасна бюрократія.

Мабуть конкуренція реалізацій більше сприяє розвиткові мови ніж її відсутність.

Можливо, але навіщо обговорювати те, чого немає? Чи якщо з’явиться стандарт, то купа розробників почнуть розробляти конкурентну реалізацію? Чи багато є конкурентних реалізацій C#? Лише Mono, який почали розробляти до стандарту, керуючись практичним запитом — зробити .NET-код кросплатформним.

Йдеться про те, що відсутність ISO стандартизації та конкурентних реалізацій, обмежує можливості та темпи розвитку мови Rust, порівняно з мовами, які то все мають.

Що, певно, збільшує шанси стати до череди, наприклад із the D programming language.

en.wikipedia.org/...​ages_with_an_ISO_standard

Я бы сказал, что по сравнению с языками в этом списке, у Rust с темпом развития все вполне збс.

Мабуть не все гаразд із Rust раз Google вкладається у Carbon, який є прямим конкурентом Rust.

Гарне питання до Chandler Carruth.

Не в тому суть. Вони там ніби хочуть добитися максимальної бінарної сумісності з C++, чого не може бути в принціпі зроблено з Rust.

може з С, чи яка в С++ сумістність?

Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest.

Саме бінарну і саме з плюсами.

а в плюсів вона є хоть самих з собом?

Мабуть конкуренція реалізацій більше сприяє розвиткові мови ніж її відсутність.

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

Сегодня:

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

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

Конкуренции практически не осталось, у большинства языков есть одна основная реализация, в которую все контрибьютят.

Підписатись на коментарі