Вот, подняли вопрос — раз LLM может писать код по формальным требованиям — то сможет ли справиться с более простой задачей — переводить с одного ЯП на другой. Под переводом подразумевается не буквальная автоматизированная трансляция — а некое "умное" преобразование с учетом нюансов.
Вроде бы задача — намного проще чем писать некие системы с нуля. Бери готовый код и просто переводи.
Ну и ключевая задача, о которой сейчас много споров и почти до мордобоя доходит — это пресловутая идея переписать ядро Линукс с гнилого C на божественный Rust.
Сможет ли LLM? Вроде задача как раз для него.
Но похоже что нет — не сможет даже этого. Причем нельзя указать какой именно кусок кода не подлежит переводу, но в совокупности задача выглядит как невыполнимая — накопление ошибки и невозможность находить эти ошибки.
Т.е., получается, нельзя в точности сказать что именно не возможно, показать пальцем. Как только покажешь пальцем — проблема исчезает. Но в целом задача считается не выполнимой автоматизированно.
Здравствуйте, Shmj, Вы писали:
S>Т.е., получается, нельзя в точности сказать что именно не возможно, показать пальцем. Как только покажешь пальцем — проблема исчезает. Но в целом задача считается не выполнимой автоматизированно.
Можно ли взять условный LLVM, и запилить транспиллер из Си в Rust? Думаю, что да. Надо ли это кому? Думаю, что нет.
P.S. Задача более объемная, чем кажется, потому что с точки зрения практической применимости, надо (1) генерировать не слишком уж пессимизированный выходной код (2) надо поддерживать расширения gcc. По крайней мере те, которые активно используются.
Здравствуйте, Pzz, Вы писали:
Pzz>Можно ли взять условный LLVM, и запилить транспиллер из Си в Rust? Думаю, что да.
Мы не знаем, скорее всего нет.
Pzz>Надо ли это кому? Думаю, что нет.
Почему же? Посмотреть будет ли работать намного медленнее — или не критично. Опять же — можно на Rust писать как бы с чистого листа — все будет нейтивное. Ведь люди хотят.
Pzz>P.S. Задача более объемная, чем кажется, потому что с точки зрения практической применимости, надо (1) генерировать не слишком уж пессимизированный выходной код (2) надо поддерживать расширения gcc. По крайней мере те, которые активно используются.
Здравствуйте, Shmj, Вы писали:
Pzz>>Можно ли взять условный LLVM, и запилить транспиллер из Си в Rust? Думаю, что да.
S>Мы не знаем, скорее всего нет.
С чего бы нет-то? Представь, что Rust — это ассемблер такой...
Pzz>>P.S. Задача более объемная, чем кажется, потому что с точки зрения практической применимости, надо (1) генерировать не слишком уж пессимизированный выходной код (2) надо поддерживать расширения gcc. По крайней мере те, которые активно используются.
S>Если вообще разрешима.
Здравствуйте, Shmj, Вы писали:
S>Вот, подняли вопрос — раз LLM может писать код по формальным требованиям — то сможет ли справиться с более простой задачей — переводить с одного ЯП на другой. S>... переписать ядро Линукс с гнилого C на божественный Rust. S>Сможет ли LLM? Вроде задача как раз для него.
А разве уже появился такой ИИ, который смог бы хотя бы переименовать функцию в проекте, в котором больше 50 тыс. строк и так, чтобы вероятность ошибки была меньше 0.001 ?
Здравствуйте, Shmj, Вы писали:
S>Почему же? Посмотреть будет ли работать намного медленнее — или не критично. Опять же — можно на Rust писать как бы с чистого листа — все будет нейтивное. Ведь люди хотят.
Кажется, что не только хотят, но и делают — Redox. Чем не устраивает, зачем обязательно переписывать Линукс с кучей легаси?
Здравствуйте, Nuzhny, Вы писали:
N>Кажется, что не только хотят, но и делают — Redox. Чем не устраивает, зачем обязательно переписывать Линукс с кучей легаси?
Ну если это бесплатно можно сделать автоматизированно — то почему нет? Единая экосистема.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Можно ли взять условный LLVM, и запилить транспиллер из Си в Rust? Думаю, что да. S>>Мы не знаем, скорее всего нет. Pzz>С чего бы нет-то? Представь, что Rust — это ассемблер такой...
Если бы можно было сделать простой конвертер из Си в Rust, чтобы воспользоваться статическим анализатором из Rust (отловить в compile time ошибки работы с памятью). То тогда можно было бы написать такой анализатор и для Си. Или нет? Если бы можно было сделать автоматически, то зачем эти ключевые слова из Rust для управления памятью?
Здравствуйте, Silver_S, Вы писали:
Pzz>>С чего бы нет-то? Представь, что Rust — это ассемблер такой...
S_S>Если бы можно было сделать простой конвертер из Си в Rust, чтобы воспользоваться статическим анализатором из Rust (отловить в compile time ошибки работы с памятью). То тогда можно было бы написать такой анализатор и для Си. Или нет? Если бы можно было сделать автоматически, то зачем эти ключевые слова из Rust для управления памятью?
Вопрос был в том, можно ли автоматически превратить работающий код на Си в работающий код на Rust. Ответ: да, можно.
Но это не значит, что можно автоматически превратить код на Си в safe код на Rust.
Здравствуйте, Shmj, Вы писали:
S>Ну и ключевая задача, о которой сейчас много споров и почти до мордобоя доходит — это пресловутая идея переписать ядро Линукс с гнилого C на божественный Rust.
S>Сможет ли LLM? Вроде задача как раз для него.
Божественность Rust-а связана с тем, что он заставляет программиста гораздо более подробно описывать свои намерения.
Миссионеры Руста считают, что таким образом можно снизить количество ошибок.
Я считаю, что это не так, но кто я такой? и вообще неважно, правда это или нет.
Важно то, что для такого "перевода" нужно вытащить информацию, которая была в голове у программиста, но сейчас в коде не присутствует.
Ну это почти то же самое что из скомпилированного кода извлечь исходник, да ещё и с человеко-понятными именами переменных и функций.
Ну и чё? Похоже это на "задачу как раз для LLM"? По моему, не очень.
Здравствуйте, alpha21264, Вы писали:
A>Божественность Rust-а связана с тем, что он заставляет программиста гораздо более подробно описывать свои намерения. A>Миссионеры Руста считают, что таким образом можно снизить количество ошибок.
Но вообще для начала хотя бы на небезопасном Rust переписать. Он так же имеет преимущества перед C.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, alpha21264, Вы писали:
A>>Божественность Rust-а связана с тем, что он заставляет программиста гораздо более подробно описывать свои намерения. A>>Миссионеры Руста считают, что таким образом можно снизить количество ошибок.
S>Но вообще для начала хотя бы на небезопасном Rust переписать. Он так же имеет преимущества перед C.
1) Какие он имеет преимущества? За счёт чего?
2) Я подозреваю, что проблемы переписывания ровно такие же.
Здравствуйте, alpha21264, Вы писали:
A>1) Какие он имеет преимущества? За счёт чего?
Да, даже небезопасный (unsafe) Rust в ряде аспектов может быть лучше C, несмотря на то, что он отказывается от основной "фишки" безопасного Rust — гарантированной безопасности памяти. Вот ключевые моменты, где unsafe Rust может выигрывать у C:
✅ 1. Строгая система типов
У Rust даже в unsafe коде остаётся гораздо строже выраженная система типов, чем в C.
Например, отличия между &T, &mut T, *const T, *mut T явно выражены, и вы не сможете случайно передать *mut туда, где ожидался &.
✅ 2. Более современный компилятор
Компилятор Rust (rustc) проводит более строгий анализ кода, чем типичный компилятор C.
Даже в unsafe блоках остаются некоторые проверки (например, инициализация переменных, сроки жизни, переменные после move и т.д.).
✅ 3. Поддержка безопасного обрамления (safe wrappers)
Вы можете изолировать unsafe участки в чётко ограниченных местах и предоставить безопасный API, тогда как в C весь код потенциально небезопасен.
Это делает unsafe Rust более контролируемым и позволяет постепенно обертывать низкоуровневый код безопасными абстракциями.
✅ 4. Оптимизации и контроль без UB
Rust по умолчанию не допускает неопределённого поведения (Undefined Behavior) в безопасном коде, и даже unsafe должен быть корректен.
В C даже тривиальные ошибки (например, выход за пределы массива или использование висячего указателя) могут сломать программу непредсказуемо.
✅ 5. Удобные макросы, системы сборки и экосистема
cargo, crates.io, #[macro_use], derive-макросы и т.д. делают работу с unsafe Rust намного продуктивнее, чем с "голым" C.
✅ 6. Более строгий контроль над владением
Даже в unsafe коде вы можете (и должны) использовать систему владения, чтобы избежать двойного освобождения, утечек или гонок.
A>2) Я подозреваю, что проблемы переписывания ровно такие же.
