RIIR. Если вы хоть немного следите за open source, то наверняка с этим сталкивались. Кто‑нибудь открывает issue в проекте на C или C++ и предлагает переписать всё на Rust ради безопасности работы с памятью и производительности. Иногда это вполне серьёзное предложение. Иногда — мем. В 2026 году, пожалуй, это и то и другое одновременно.
Нам захотелось разобраться, что из этого ближе к реальности. Не в теории, а на примерах проектов, которые действительно решились на такой шаг: какие преимущества они получили, что случилось с производительностью, какие проекты забросили спустя три года работы и какие CVE обнаружились в только что написанном Rust‑коде. Мы достаточно давно варимся в этой экосистеме и успели увидеть всё перечисленное. Эта статья основана на докладе с Rustikon 2026 и представляет собой попытку без прикрас разобраться, что на самом деле происходит с RIIR.
TL;DR
RIIR действительно может повысить производительность и безопасность, но сам по себе Rust ничего не гарантирует. Одни проекты ускорились благодаря Rust, другие — просто потому, что их переписали с нуля.
При переписывании появляются новые баги. Ошибаются даже опытные инженеры в командах с хорошим финансированием.
Далеко не каждое переписывание заканчивается успехом. Prisma, Loglog Games и интеграция curl с hyper столкнулись с серьёзными проблемами, причём по разным причинам.
Размер бинарников, поддержка платформ и взаимодействие с другими языками остаются вполне реальными практическими проблемами.
Почти всегда лучше внедрять Rust поэтапно, а не переписывать всё сразу.
Появление Rust в ядре Linux и Windows, пожалуй, стало самым весомым подтверждением жизнеспособности идеи RIIR за всё время её существования.
Что такое RIIR и почему эта идея стала популярной?
RIIR расшифровывается как Rewrite It In Rust — «перепишите это на Rust». Фраза начала появляться в issue‑трекерах проектов на C и C++ как предложение перейти на производительную альтернативу с безопасной работой с памятью. По данным Google Trends, интерес к запросу «rewrite rust» начал заметно расти примерно в 2022 году. Кажется, это примерно совпало с выходом Rust 2021 Edition, хотя в тот период происходило много всего, поэтому утверждать, что причина именно в этом, мы не берёмся.
Когда разработчики задумываются о переписывании проекта и выбирают Rust, обычно их привлекают три вещи:
Безопасность работы с памятью
Производительность
“Бесстрашная конкурентность” (fearless concurrency)
Что касается безопасности работы с памятью, с данными команды Android спорить сложно. После того как в Android при разработке нового кода начали переходить на языки с безопасной работой с памятью, объём добавляемого в кодовую базу Rust‑кода стал стабильно расти. Данные показывают чёткую линейную корреляцию: чем меньше нового кода без гарантий безопасности работы с памятью, тем меньше и уязвимостей, связанных с памятью.
Что до производительности, в исследовании 2017 года, где языки программирования сравнивались по энергоэффективности, времени выполнения и потреблению памяти, Rust оказался среди лидеров и по энергоэффективности, и по скорости выполнения. Методика исследования не идеальна, да и напрямую сравнивать языки непросто, но результаты всё же отражают общую картину: Rust способен на равных конкурировать с другими языками и по скорости, и по эффективности. По потреблению памяти он уступал абсолютным лидерам, но всё равно находился в верхней половине рейтинга.
А ещё есть опрос разработчиков Stack Overflow. Rust уже несколько лет подряд остаётся самым любимым языком среди разработчиков. И вполне вероятно, что немалая часть RIIR‑проектов существует просто потому, что разработчикам хочется писать на Rust. Это тоже стоит признать.
Три типа переписывания
Не все переписывания одинаковы, поэтому полезно сразу уточнить, о каком именно типе идёт речь. Мы выделили три категории.
Полностью совместимые замены (drop‑in replacements) стремятся полностью повторить функциональность оригинала. Вы просто заменяете бинарник, а всё остальное продолжает работать как раньше. К этой категории относятся, например, uutils coreutils, sudo‑rs, youki как замена контейнерного рантайма и Arti как новая реализация Tor. Таких проектов в экосистеме тысячи: от небольших библиотек для работы с файловыми форматами, вроде PNG‑крейта, заменяющего libpng, до крупных инфраструктурных проектов с серьёзной поддержкой компаний и сообщества.
Альтернативы решают ту же задачу, но делают это иначе. ripgrep вместо grep, delta вместо diff, bat вместо cat, Typst вместо LaTeX, Polars вместо pandas. Они не пытаются быть полностью идентичной заменой. Часто такие проекты быстрее, удобнее или просто строятся вокруг другой философии. Typst хорошо показывает преимущество с точки зрения читаемости:
LaTeX и Typst способны дать один и тот же результат, но исходный код у них выглядит совершенно по‑разному. А если говорить о чистой производительности, Марек запустил ripgrep и grep на каталоге target от Cargo размером 37 ГБ и искал слово cot. grep справился за 52 секунды. ripgrep — за шесть. Это уже не небольшая разница.
Переписывание собственного проекта на Rust (self‑rewrite) — это ситуация, когда существующий проект решает переписать на Rust часть своей кодовой базы или всю её целиком, не заменяя при этом какой‑то внешний бинарник. Сюда относятся Firefox, ядро Linux, Windows, инфраструктура Cloudflare и оболочка Fish. И это уже совсем не маленькие эксперименты. Сегодня Rust используется в некоторых из самых массово развёрнутых программных систем в мире, и пришёл он туда именно таким путём.
Производительность после переписывания на Rust: действительно ли становится быстрее?
Иногда да. При том иногда — не по вполне очевидным причинам.
Например, в uutils утилита sort работает почти в четыре раза быстрее GNU sort. Причина — параллельная сортировка слиянием, которую благодаря модели конкурентности Rust заметно проще реализовать корректно. Но некоторые другие утилиты быстрее просто потому, что это новая реализация, созданная с учётом 30 лет накопленного опыта. У оригинального проекта не было такой свободы для экспериментов: от него зависели пользователи в продакшене.
PNG‑крейт — более показательный пример преимуществ, связанных именно с Rust. Реализация на Rust почти вдвое быстрее libpng. Отчасти это результат автовекторизации: компилятор Rust автоматически генерирует SIMD‑инструкции из обычного цикла for, тогда как в большинстве реализаций на C SIMD приходится писать вручную. Второй фактор — потоковая декомпрессия DEFLATE, благодаря которой за один раз в кеш процессора помещается больше данных. И то и другое уже можно считать реальными преимуществами Rust.
Размер бинарников Rust: в чём проблема и как её решают
Бинарники Rust славятся своим размером, и причины вполне конкретные: код для обработки panic, реализации трейта Debug, стандартная библиотека, включаемая в каждый бинарник, мономорфизация дженериков и статическая линковка всех зависимостей.
В uutils эту проблему решили с помощью формата мультиколл‑бинарника (multicall binary) — того же подхода, который использует BusyBox. Все утилиты компилируются в один бинарник и вызываются через символические ссылки. В итоге 73 МБ отдельных бинарников превращаются в 13,8 МБ одного мультиколл‑бинарника — это даже меньше, чем 18,4 МБ у стандартной установки GNU coreutils. После сжатия UPX размер уменьшается до 5 МБ.
Проблему можно решить, но для этого придётся серьёзно потрудиться.
Переписывание на Rust: что может пойти не так и почему?
Об этом говорят недостаточно: любое переписывание приносит новые баги. Вы пишете код с нуля, а значит, неизбежно получите ошибки или регрессии, которых не было в исходном проекте. Это проблема не конкретно Rust, а переписывания ПО как такового. Но важно смотреть на неё трезво.
Cloudflare допустила вызов unwrap в компоненте оценки запросов. uutils немного неправильно форматировал даты, из‑за чего ломались автоматические обновления. sudo‑rs после тайм‑аута выводил обратно в терминал уже набранную часть пароля. Первая CVE в Rust‑коде ядра Linux появилась из‑за состояния гонки в unsafe‑блоке драйвера Android Binder. TARmageddon — RCE‑уязвимость в async‑tar — возникла из‑за некорректного разбора формата.tar.
Если такие ошибки допускают даже опытные команды с серьёзным финансированием, будем допускать и мы. Это не повод отказываться от переписывания, но веская причина относиться к тестированию всерьёз.
А иногда Rust вообще оказывается не лучшим выбором. Microsoft выбрала Go для переписывания компилятора TypeScript во многом потому, что модель программирования Go гораздо ближе к TypeScript. Это было особенно важно, поскольку довольно долго в одной кодовой базе должны были сосуществовать оба языка. Проект NTPsec тоже выбрал Go: на тот момент у него были более удобные сетевые примитивы и менее фрагментированная экосистема. Это вполне рациональные решения, а не недостаток амбиций.
Более того, некоторые проекты выбрали Rust для переписывания, но всё равно не добились успеха. Prisma отказалась от движка запросов на Rust и вернулась к TypeScript из‑за нехватки нужной экспертизы в команде, сложностей с развёртыванием и проблем с рантаймом. Loglog Games отказалась от Rust после трёх лет разработки игр. По их опыту, Rust отлично подходит для рефакторинга, но плохо — для быстрых итераций. Они также отметили, что Rust‑сообщество в геймдеве больше сосредоточено на технических деталях движков, чем на выпуске законченных игр. Интеграция curl с hyper дошла до 95% готовности, после чего её забросили: последние 5% оказались слишком сложными, а интерес сообщества сошёл на нет. При этом сотрудничество всё равно пошло обоим проектам на пользу: попытка интеграции заставила разработчиков навести порядок в обеих кодовых базах.
Лицензия — это тоже важное решение
Есть ещё один аспект, который в обсуждениях RIIR часто обходят стороной: если вы создаёте новый проект, реализующий функциональность уже существующего, выбор лицензии будет иметь вполне практические последствия.
Более строгая лицензия вроде GPL может отрезать пользователей, которые не могут добавлять в проприетарные проекты зависимости с copyleft‑лицензиями. Более разрешительная лицензия, наоборот, может вызвать критику со стороны open source‑сообщества: некоторые опасаются, что компании будут пользоваться кодом, ничего не отдавая взамен. Универсально правильного ответа здесь нет. Всё зависит от целей проекта и его сообщества. Но это решение стоит принимать осознанно, а не просто оставлять вариант по умолчанию.
Живо ли движение RIIR в 2026 году?
Сам мем RIIR немного поутих. Но само движение никуда не делось. Rust в ядре Linux больше не считается экспериментом, а на Maintainers Summit 2025 мейнтейнеры признали эксперимент успешным. Rust работает и в ядре Windows. Cloudflare, Firefox и множество инфраструктурных проектов уже используют значительные объёмы Rust‑кода в продакшене.
Масштаб действительно огромен. Только благодаря Linux и Windows Rust сегодня работает на миллиардах устройств. Пожалуй, это самое весомое подтверждение жизнеспособности идеи «переписать на Rust» за всё время её существования.
Как сделать всё правильно
Если вы задумались о переписывании проекта, сначала стоит ответить на несколько вопросов. Действительно ли Rust подходит для вашей задачи? Написана ли кодовая база на языке без гарантий безопасности работы с памятью? Насколько критично это ПО? Есть ли реальные требования к производительности и надёжности? Много ли в проекте параллельного или конкурентного кода, в котором сложно разобраться? Чем больше ответов «да», тем весомее аргументы в пользу переписывания.
Убедитесь, что команда к этому готова. Разработчики либо уже должны знать Rust, либо действительно хотеть его освоить и работать с ним. По данным Google, примерно две трети разработчиков уже через два месяца чувствуют себя достаточно уверенно, чтобы вносить изменения в кодовую базу на Rust. Но никаких гарантий здесь нет, а последние 5% переписывания почти всегда оказываются сложнее, чем кажется. Небольшие проекты занимают месяцы. Средние — от одного до двух лет, крупные — от двух до пяти. Почти всегда всё длится дольше первоначальных оценок.
По возможности внедряйте Rust поэтапно, а не переписывайте проект целиком. Добавлять новые компоненты на Rust, сохраняя работающую старую кодовую базу, почти всегда менее рискованно, чем полностью её заменять. Так можно получить преимущества Rust, не ставя на кон весь проект.
А если всё же что‑то переписываете, создайте серьёзный набор тестов. Один из лучших примеров — uutils, который прогоняется на официальном наборе тестов GNU coreutils, чтобы отслеживать соответствие поведению оригинала. На начало 2026 года доля успешно пройденных тестов составляет 92,2% и продолжает расти.
Так стоит ли оно того?
Если ваш проект написан на языке без гарантий безопасности работы с памятью, выполняет критически важные функции, предъявляет серьёзные требования к производительности и содержит много конкурентного кода — да. В таком случае переписывание вполне оправдано, и имеющиеся данные это подтверждают.
В остальных случаях оно тоже может иметь смысл, но решение требует более тщательной оценки. Энтузиазм вокруг Rust понятен: язык действительно хорош. Но Rust создавался прежде всего для системного программирования, и именно там раскрывается лучше всего. Если воспринимать RIIR как универсальный ответ на любые проблемы с производительностью или безопасностью, легко получить двухлетний проект по переписыванию, который выйдет на полгода позже срока и заново принесёт баги, когда‑то уже исправленные в старой кодовой базе.
FAQ
Что означает RIIR?
RIIR расшифровывается как Rewrite It In Rust — «перепишите это на Rust». Изначально эту фразу использовали в issue‑трекерах open source‑проектов, предлагая переносить проекты с C и C++ на Rust ради безопасности работы с памятью и производительности. Со временем она превратилась в отдельный мем Rust‑сообщества.
Стоит ли переписывать ПО на Rust?
Зависит от ситуации. Если кодовая база написана на языке без гарантий безопасности работы с памятью, выполняет критически важные функции и предъявляет серьёзные требования к производительности или конкурентности, аргументы в пользу переписывания на Rust довольно весомы. В других случаях преимущества уже не так однозначны, а цену перехода — порог входа в язык, сроки переписывания и неизбежное появление новых багов — стоит оценивать особенно внимательно.
Какие риски несёт переписывание на Rust?
Любое переписывание приносит новые баги, в том числе те, которые в исходном проекте уже когда‑то исправили. Кроме того, разработчикам придётся освоить Rust, сам процесс может занять гораздо больше времени, чем предполагалось, а ещё могут возникнуть проблемы с поддержкой платформ, размером бинарников и взаимодействием с другими языками.
Как лучше всего переходить на Rust?
Внедрять Rust поэтапно, а не переписывать всё сразу. Добавляйте новые компоненты на Rust, сохраняя существующий код в рабочем состоянии. А когда что‑то действительно переписываете, вложитесь в полноценный набор тестов, который проверяет, что новая реализация ведёт себя так же, как исходная.
Удалось ли успешно внедрить Rust в ядро Linux?
Да. На Linux Kernel Maintainers Summit 2025 участники пришли к выводу, что эксперимент с Rust оказался успешным. Теперь Rust считается полноценной частью ядра и больше не имеет экспериментального статуса.
Продолжить тему можно на бесплатных уроках от преподавателей Otus. Это возможность разобрать Rust и управление памятью на практике, оценить формат обучения и задать вопросы по темам, в которых остались пробелы.
23 сентября, 20:00. «Создание кроссплатформенного приложения с GUI на Rust: от идеи до реальности». Записаться
24 сентября, 20:00. «Указатели в Си — от адреса к управлению памятью». Записаться
Полный список бесплатных уроков сентября смотрите в дайджесте.
Комментарии (49)
EgorSharin
19.09.2026 12:29NSA (АНБ США) выпустили список языков, разрешаемых для проектов, чтобы разрешалось работать с пиндоским правительством. (Коряво написал, пардон... ещё с утра кофием не заправился...)
Из языков с высокой скоростью работы - только Rust.
ALifeIsAMoment
19.09.2026 12:29значит бекдор на уровне компилятора уже внедрён)
Других же у раста нет, чтобы байт-код сравнивать.
Medeyko
19.09.2026 12:29В коде, полученном из исходника на Rust, нет никакого байт-кода!
А альтернативные компиляторы есть:
rustc_codegen_gcc - бэкенд GCC. Генерирует код при помощи GCC из промежуточного представления, сгенерированного rustc.
gccrs - фронтенд GCC. Полная независимая реализация компилятора Rust внутри экосистемы GCC.
EgorSharin
19.09.2026 12:29Интересно, какие дебилы заминусовали мой комментарий с официальной информацией, со ссылкой на американский государственный сайт???
Что я, по их дебильному мнению, написал неверно или грубо или не в тему или ещё как-то нехорошо/неправильно???
Интересно, какой у этих минусователей средний коеффициент интеллекта? Или там вообще измерять нечего?..
Medeyko
19.09.2026 12:29Я Ваш комментарий заплюсовал (за его суть), но от слова "пиндоским" тоже поморщился - не нужно оно на Хабре; думаю, минусуют Вас именно за него.
sanchas
19.09.2026 12:29Я не очень понимаю желание переписать на Rust древний C/C++ код который был отлажен не то что годами, а десятилетиями. Выигрыш в производительности будет только если что-то оптимизировать (а это не всегда возможно). Выигрыш в надежности - может быть, если не допустить ошибок при переписывании, а они наверняка будут. Если конечно прям очень хочется - я не возражаю. Но особого смысла не вижу.
Если уж переписывать что-то на Rust, то это проекты на Python и NodeJs. Там увеличение производительности будет гарантировано.
Dhwtj
19.09.2026 12:29Выигрыш в значительном сокращении рисков уязвимостей типа memory corruption. Хоть ты 10 лет эксплуатируй а хитрый взлом найдется
MountainGoat
19.09.2026 12:29А желающих поддерживать древний код становится меньше. Код на Раст гораздо понятнее при чтении, чем некоторые варианты С++, особенно древние. Там нет этих конструкций из знаков препинания, которые сами по себе выглядят так, словно ты открыл в блокноте бинарник. Код на Расте легче изменять - кучу ошибок класса "изменил незначительно, но в чужом коде началось UB" Раст тоже ловит.
Переписывать на Раст код, который никто уже не будет обновлять или патчить безопасность, действительно нет никакого смысла.
Wesha
19.09.2026 12:29желающих поддерживать древний код становится меньше
Способных поддерживать древний код становится меньше.
Это ж работать надо!
JerryI
19.09.2026 12:29Да, напереписывались, в Ubuntu приходится переставлять системные утилиты gnu, иначе всякие хэши неверно считает.
unC0Rr
19.09.2026 12:29При этом coreutils - тот самый "древний C/C++ код который был отлажен не то что годами, а десятилетиями" - в апреле закрывал проблемы с памятью в pwd.
ss-pol
19.09.2026 12:29Если уж переписывать что-то на Rust, то это проекты на Python и NodeJs. Там увеличение производительности будет гарантировано.
Очень редко увеличение производительности проекта на питоне и ноде настолько критично, чтобы жертвовать читабельностью, простотой кода, лёгкостью поддержки и вообще затратами времени на переписывание. Те, кому нужна производительность изначально питон и ноду не берут. Так что остаётся только повышенная безопасность, но в питоне и ноде безопасность памяти уже есть и она гораздо дешевле в смысле разработки и поддержки.
Выигрыш в надежности - может быть, если не допустить ошибок при переписывании, а они наверняка будут. Если конечно прям очень хочется - я не возражаю. Но особого смысла не вижу.
Тут я дополню, почему ещё не стоит спешить переписывать для снижения количества ошибок с памятью. Комитет с++ уже работает над безопасными профилями, так что лет через 5, надеюсь, вполне можно будет повысить безопасность кода и без переписывания всего и вся. Если какие-то куски переписывать и придётся, то это будет привычный с++ с нововведениями.
v_0ver
19.09.2026 12:29Ну переписывают не так уж и много, обычно просто пишут альтернативу, на которую в последствии переходят.
Format-X22
19.09.2026 12:29У меня в телеграмме набор стикеров с мемами про переписывание на Rust был ещё в 2017. С момента появления языка на него уже хотели всё переписывать.
А вот с TypeScript это печальный выбор, компилятор на расте был бы конечно более органичным. А вообще показательно что TS не смог работать на самом себе. И грустно. Звучит как предательство идеалов. Но это мои субъективные мысли как человека с 15 годами в JS/TS, теперь нода выглядит как неизбежный переход бекендов на Go, за исключением проектов где серверный рендеринг и прочее.
А с играми и прочим много веселья. Из коробки борроу чекер не даст иметь две ссылки на два элемента в массиве. В итоге скатывается всё к тому что хранят индексы вместо ссылки, по сути самодельная ссылка. И эта ссылка может становиться битой, если в массиве больше нет такого элемента, либо там начинает лежать что-то другое, особенно при многопоточности. И в итоге вся идея с безопасностью ссылок рушится на этом месте. Конечно кроме массивов и рекурсивных структур ещё много чего есть и там безопасность теперь гарантируется. Но остаются вот такие кейсы и они боль. Также как замена ошибок через anyhow крейт - боролись за обработку всех ошибок, но из-за того что нельзя вернуть ошибки разных типов из метода - либо на каждую строку ручная унылая конвертация в общий тип, либо anyhow с потерей в безопасности.
И всё же Rust хорош, для своей ниши он реально упрощает разработку, на нем проще писать - компилятор уже подумал за тебя, а меньше багфиксов - быстрее деливери. И сборка мусора на этапе компиляции это действительно новый подход, берущий от двух миров лучшее. Конечно в плюсах и прочем есть протоколы как примерно также писать, но на уровне языка так сделать - шаг весьма хороший. Rust действительно привнес нового в мир программирования, не так часто такое бывает. Языки где просто по своему делали всякие корпорации и энтузиасты часто, а вот парадигму новую не каждый может привнести.
MountainGoat
19.09.2026 12:29Но остаются вот такие кейсы и они боль.
Везде, где есть стена, об неё можно убиться с разбегу.
ALifeIsAMoment
19.09.2026 12:29Раст для разработки игр проходит подходит. Разве что готовую игру на раст переписывать)
Dhwtj
19.09.2026 12:29унылая конвертация в общий тип
Выше уровнем она мапится (люблю это делать через from, тогда в бизнес логике чисто, только вопросик), а кто умный тот и обработает - сервис повторит запрос или рендер покажет ошибку пользователю.
Так что не вижу проблем, с обработкой ошибок всё отлично в Rust. Надо только помнить, что ошибки тоже часть логики и сразу проектировать с ними.
Pongo
19.09.2026 12:29компилятор на расте был бы конечно более органичным
А почему?
В своем недавнем интервью Андерс Хейлсберг как раз говорит, что Go, с его сборкой мусора, более подходящий выбор, чем Rust. Тем более, что они делали порт, а не переписывали.
Medeyko
19.09.2026 12:29Битый индекс ("самодельная ссылка") - это совсем не то же самое, что и битый указатель. Битый индекс - куда меньшая проблема с точки зрения уязвимостей. Проблема в этом случае носит локализованный характер. Ну, будет обработан другой однородный объект - это не произвольные неожиданные места в случае указателей. И ловить такие ошибки тоже легче, потому что, опять же, это не порча памяти в каком-то никак не связанном месте, которая всплывёт непонятно когда.
Akon32
19.09.2026 12:29Почти то же самое. При записи по индексу в другой массив данные будут повреждены, а при чтении из другого массива - прочитается то, что читать не следует. Почти как с указателями, только они могут сбоить при доступе к неаллоцированной памяти, а индексы - при доступе за пределы другого массива.
Medeyko
19.09.2026 12:29Что за другой массив?
Если Вы перепутали имена переменных, то индексы тут ни при чём - с таким же успехом Вы можете перепутать имена любых объектов.
Если Вы имеете в виду, что индекс может выйти за пределы "родного" массива и попасть на память другого - то нет, не может. В Rust выход за границу массива по умолчанию проверяется даже в release-сборке.
unC0Rr
19.09.2026 12:29Есть библиотеки для индексов, прибитых к массиву, если нужно. Например, index_type.
sdramare
19.09.2026 12:29компилятор на расте был бы конечно более органичным
Го структурно ближе к тайпскрипту, это экономически правильное решение.
нода выглядит как неизбежный переход бекендов на Go, за исключением проектов где серверный рендеринг и прочее.
Самая идея написания бэкэнда на скриптовом языке для гипертекстовых документов изначально была тупиковой.
Из коробки борроу чекер не даст иметь две ссылки на два элемента в массиве.
Из коробки есть
get_disjoint_muthttps://doc.rust-lang.org/std/primitive.slice.html#method.get_disjoint_mut
нельзя вернуть ошибки разных типов из метода
Конечно же можно, для этого есть enum
Format-X22
19.09.2026 12:29Самая идея написания бэкэнда на скриптовом языке
Ну Python, Ruby, PHP и Perl считают что не так всё однозначно. И процент бекендов на этом стеке близок к 95.
Конечно же можно, для этого есть enum
Это если наши собственные ошибки. А если надо сходить по апи, в базу и попутно вызвать метод из сторонней либы - будет три разных типа и нужно их по одному обрабатывать, либо anyhow и box dyn.
sdramare
19.09.2026 12:29Ну Python, Ruby, PHP и Perl считают что не так всё однозначно
Все довольно одназначно - эти языки изначально не для гипертекстовых документов, а для сервера.
А если надо сходить по апи, в базу и попутно вызвать метод из сторонней либы
То это 3 разных действия и их ошибки напрямую и не должны подниматься наверх, потому что произойдется потеря семантики и контекста. Наверх должна отдаваться ошибка соотвествующая доменной области, а не сырой абстрактный IO Error. А если вы их обратываете и клиент вашего компонента о них даже не знает, то вам тем более не нужен anyhow и box dyn.
Apoheliy
19.09.2026 12:29Пардонь-те,
Я понимаю, что Матеуш с Мареком такие статьи пишут.
Понимают, когда их переводят на понятный язык.Чего не понимаю: почему такое обсуждение в стиле
"перейду на Rust со следующего понедельника"?Вот зашёл на известный поисковик работы. Вбил Rust, убрал вакансии, не обновляющиеся больше 3-х дней - получил выборку из 2-х (ДВУХ, КАРЛ!) вакансий, одна из которых похоже и не про раст.
Вот и расскажите мне: и язык может хороший. и торвальдс его пытается разрешить, протолкнуть.
Но кто? Кто будет первоначально писать код? Кто будет потом поддерживать этот код?
Или всё свалим на ИванИваныча?
Прим: или я не туда смотрю и вакансий на rust овердофига и "просто не в теме". В этом случае лучше откомментировать "ты не прав".
Format-X22
19.09.2026 12:29Бывают вакансии, просто мало. А сейчас со сдутием IT-сектора ещё меньше. К слову, на Rust ещё пишут смарт-контракты для крипты - в топ-3 по оборотам крипте Rust - нативный язык контактов. Уверен это добавило языку популярности, помимо прочего. Когда начнется новый цикл роста - добавится ещё оттуда вакансий. Ну и HFT-фонды используют Rust, потому что очень быстро, а встроенная надежность хороша для денег. Я касался проекта где как раз под крипту боты на Rust были и там задача была успеть первым. У владельца фонда была яхта, так что как минимум в прошлом году они успевали. И там был штат растовиков. Так что за весь рынок не скажу, но в финтехе спрос есть.
v_0ver
19.09.2026 12:29Вакансий действительно мало. И они обычно закрываются внутренними ресурсами - теми кто хочет свичнутся из Python/Java/Go/С++ итд. Либо через рекомендации.
Поэтому вакансий действительно мало, но больше чем публично видно.
peschex0d
19.09.2026 12:29Мне надо перепаковать архив вложений форума из примерно 9 тысяч файлов из .tgz в оригинальный формат файлов, при этом 7z не распаковывает сразу и .tar извлекаемый из .tgz
Это умеет untgz.
Я нашёл 1997 года проект untgz с его версией исходников для Борланд си 5, но про него конечно же пишут, уязвимый код для атаки через длинные параметры командной строки, ибо в коде strcpy() без проверки, что строка помещается в буфер. Ну и прототипы функций в K&R стиле, до-ANSI вишенкой на торте.
Без каких-либо проблем добавил в main() контроль длины копируемых строк, почистил прототипы, скомпилировал win32 PE консольное приложение тем же Борланд си++ пятой версии (который, к слову, в архиве 15 мегабайт и в роли IDE редактор FAR manager-а) и задача в принципе решена.
Переписывать untgz на rust, чтобы что?
Dhwtj
19.09.2026 12:29Чтобы закрыть уязвимости. Бомба в архиве и ваши деньги уже перечислены мошенники.
Без каких-либо проблем добавил в main()
Когда уязвимость найдена, то каждый дурак (и вы тоже) сможет
peschex0d
19.09.2026 12:29В этом и вывод, закрыть большинство найденных уязвимостей элементарно можно без переписывания на rust
При этом, иронично, за четверть века исправленный untgz так и не опубликован, хотя даже автор жив и пишет в бложик.
Dhwtj
19.09.2026 12:29А НЕ найденных?
peschex0d
19.09.2026 12:29я понимаю, куда вы клоните ) но отвечу байкой из личной практики. В эпоху shareware мне пришлось делать колхозную систему регистрации для своей программы, при этом учебники по снятию обёртки Asprotect Солодовникова не публиковал только ленивый
мне удалось выкрутиться, в том смысле, что каждый мой серийник содержал не только уникальные данные, но и фиксированную фразу, по наличию которой после расшифровывания программа делала вывод о легальности ключа.
в качестве алгоритма шифрования использовал GIF сжатие, хехе и примитивные трюки ухода от дизассемблера.безусловно, каждый не взломанный софт (а у меня были только украденные купленные по левым картам ключи) можно сдвинуть в кучу неуловимых джо, которые нафиг кому сдались, но я больше двадцати лет живу в своей квартире, купленной за доход от регистраций.
peschex0d
19.09.2026 12:29Есть интересный пример уязвимости в zlib и как следствие в libpng и всех браузерах, освобождение ранее уже free()-d указателя памяти, который известен многими годами присутствия в исходниках вопреки разглядыванию их неопределенным кругом лиц разработчиков и кого попало, который теоретически можно эксплуатировать, но практически так никто и не продемонстрировал, например, хотя бы запуск notepad.exe через просмотр эджем или файрфоксом специально подготовленного .png файла
В этом контексте стремление что-то переписывать, рискуя внести ошибки логики работы, ради эфемерного удовлетворения от закрытой уязвимости, на эксплуатацию которой за десятилетие не нашлось мозгов ни белых, ни черных хакеров, мне кажется, такое себе.
PavelBelyaev
19.09.2026 12:29Посмотрел картинку с бенчмарками, интересно что мой любимый php не на самом низу и даже обгоняет питон
aeder
19.09.2026 12:29Если картинка со сравнением запуска утилит grep реально такая, как они были запущены - то картина полностью ложна.
На первом запуске прокэшировались все каталоги, имена файлов и содержимое файлов.
Если машина была с достаточным объемом памяти - могло полностью закэшироваться содержимое, 37 гигабайт - это по современным меркам немного.
Более того, 6 секунд - это чисто физически мало для того, чтобы считать 37 гигабайт с диска. Даже с SSD.
-------------------------------
Реально, замеры производительности таких утилит надо делать очень аккуратно, с учётом кэширования. Ну для начала - 20 раз запускать эти утилиты по очереди и усреднить результаты.
TimurZhoraev
19.09.2026 12:29обычно на Линуксе это делается монтированием в память для каждого запуска, тогда утилиты будут в +- одинаковых условиях, помимо всего прочего нужно отключать другие процессы и тяжёлый сетевой обмен. Вообще говоря сравнивать быстроту i/o, всё равно что на printf, это ещё то... помнится мерились как там шустро на экран пишет в консоль на 386-м и 486. Благо тогда и частота росла вместе с поколением. Что касается утилит - плюс ещё обработки различных исключений, может быть такое что вырваны там переполнение, ошибки потока, всякие проверки итд. Программа может быть быстрой но сваливаться при первом чихе, решение безопасной памяти это полумеры на многопоточке особенно. Раст ещё не стандартизирован и там фактически один поставщик для компилятора, что для энтерпрайза даёт вопрос "а потом кому звонить если что". Питон конечно тоже этим страдает но он уже фактически стал а-ля Паскаль в 90е, в каждой школе как Бэйсик + феноменальная кодовая база всего и обо всём. В вычислениях потеснил Matlab. Не говоря уже про знаменитсость С и плюсов. Всё остальное это бег вокруг скобок и предпочтений. По факту уже привели всё к LLVM а что там сверху уже не особо интересно в эпоху LLM. Да и наверняка сам модуль memory-safe для компилятора исчезающе мал по сравнению с остальным, по современным меркам - плагин для плюсов, кстати они поддерживаются gcc, даже где то проект видел.
Akon32
19.09.2026 12:29Более того, 6 секунд - это чисто физически мало для того, чтобы считать 37 гигабайт с диска. Даже с SSD.
Эти не так. SSD уже несколько лет могут выдавать 10-15 ГБ/с.
KiddingBanana
19.09.2026 12:29На последовательное чтение. Вряд ли в тестах подразумевался один большой файл. Скорее всего там было достаточно большое дерево, а на случайном доступе у SSD все далеко не так хорошо
Dhwtj
Из знакомых на раст пишут только студенты.
Остро, модно, молодёжно.
Ну и у меня одна утилита на прод ушла
ss-pol
студенты это наше завтра
peschex0d
Наше завтра - это то, в кого они превратятся, перестав уже быть студентами)
Я имею ввиду, трезвость мышления и прагматизм вырастет, а склонность к авантюрам снизится, поэтому вполне возможно rust обратно отойдет в категорию экзотики, поиграть и отложить.
Dhwtj
Послезавтра
Medeyko
"The Day After Tomorrow"?
Dhwtj
Ага, зомбаки
LuciusWill
Старики консерваторы. Какая неожиданность.