На своём MacBook M4 я не замечал проблем. Два скрипта на Node.js 18 собирали информацию по проекту, обходили файлы, считали строки, агрегировали данные и отрабатывали за пару секунд. Жить можно.
А потом на созвоне коллега расшарил экран. У него удалённый рабочий стол, Intel Core i5-1035G1, 8 ГБ RAM. Он запустил тот же скрипт, и мы оба смотрели на терминал восемь секунд. В тишине. Восемь секунд это много, когда ты запускаешь скрипт десять раз в день.
Я переписал оба скрипта на Rust с помощью AI-ассистента (Claude Code). Получил 5-10x ускорение. Ниже то что сработало, что нет, и стоит ли вам делать то же самое.
Контекст
Два CLI-скрипта для внутренних нужд проекта:
Скрипт 1: рекурсивный обход директорий через glob, подсчёт строк в файлах по расширениям, вывод агрегированной статистики.
Скрипт 2: парсинг Markdown-файлов, извлечение front matter, построение индекса контента.
Оба на Node.js 18. На M4 работали незаметно. На железе коллеги тормозили ощутимо. Проект рос, файлов становилось больше, и разрыв в производительности между машинами только увеличивался.
Проблемы в коде были понятные: старый glob без оптимизации, промисы запускались последовательно вместо параллельного выполнения. Можно было исправить на Node.js. Но когда видишь, как коллега ждёт по 8 секунд на каждом запуске хочется решить проблему с запасом, а не впритык.
Почему Rust, а не оптимизация Node.js
Прагматичный ответ: скрипты делали ровно то, в чём Rust силён file traversal и CPU-bound агрегация. Это тот же класс задач, где ripgrep и fd показывают 10-20x ускорение по сравнению с системными grep/find.
Непрагматичный ответ: было интересно проверить, насколько реально использовать AI для генерации кода на незнакомом языке в production-сценарии.
Важно: я осознанно выбрал простую задачу. Два скрипта, каждый это пара сотен строк, без сложной бизнес-логики, без сетевых вызовов, без многопоточности. Идеальный кандидат для эксперимента. На сложном проекте с архитектурными решениями результат был бы другим.
Процесс
Отдал оба скрипта Claude Code с задачей переписать на Rust. Дальше произошло кое-что, что хорошо иллюстрирует, почему Rust + AI-генерация работает лучше, чем ожидаешь.
Компилятор Rust нашёл проблемы в сгенерированном коде. AI их исправил. Итеративно, без моего участия в отладке. Строгая система типов Rust создаёт tight feedback loop: ошибки конкретные, с указанием места и причины. Не размытые runtime-ошибки чёткий сигнал. Компилятор фактически выступает code reviewer для AI.
Что я делал: ревью финального кода (~20 минут). Читал, проверял логику, сравнивал с оригинальными скриптами. Код был понятный, Rust читается проще, чем пишется.
Чего я не делал: не отлаживал, не гуглил ошибки компилятора, не разбирался с lifetimes.
Распространение бинарников
Отдельная задача это как доставить Rust-бинарники в проект. Они platform-specific, хранить в git очень плохая идея.
Посмотрел на подход esbuild: npm-пакеты с platform-specific бинарниками. npm install и получаешь бинарник для своей ОС. Без исходников в репозитории, без тяжёлых файлов. Сделал так же вышло лучше чем ожидал.
Результаты
Машина |
Node.js 18 |
Rust |
Ускорение |
|---|---|---|---|
i5-1035G1, 8 ГБ RAM |
~8 сек |
~1-1.5 сек |
5-7x |
MacBook M4 |
~2 сек |
~0.3 сек |
~6x |
Результат предсказуемый для данного класса задач (file I/O + CPU-bound обработка). Не уникальный: ccusage показал до 1000x ускорения отдельных операций после миграции с Node.js на Rust.
Где это не сработает
Честность важнее хайпа. Вот ограничения:
По задаче:
Если узкое место сеть (API вызовы, база данных), выигрыш будет минимальный. Rust не ускорит ожидание ответа от сервера.
Если скрипт и так быстрый (< 1 сек) овчинка не стоит выделки.
Профилируйте перед тем, как переписывать.
node --profили простоtime node script.jsубедитесь, что bottleneck там, где думаете.
По подходу (AI-генерация):
Простые скрипты для меня ок. Сложная архитектура с десятками модулей, trait objects, async runtime совсем другая история.
Я не стал Rust-разработчиком. Я могу читать этот код и вносить мелкие правки через AI. Но если понадобится серьёзный рефакторинг для меня это будет проблема. Хотя всегда можно подучиться.
Зависимость от AI для обслуживания кода на языке, который не знаешь это технический долг. Осознанный, но долг. И не факт, что кроме тебя его вообще кто-то поймет и вообще сможет исправить.
Итого
Для конкретного класса задач (CLI-утилиты, file traversal, CPU-bound обработка) переписывание Node.js → Rust через AI-ассистента дало предсказуемый результат: 5-10x ускорение при минимальных затратах времени.
Подход работает, когда:
Задача простая и изолированная
Bottleneck в CPU/I/O, а не в сети
Вы готовы к тому, что обслуживание кода будет через AI
Не работает, когда:
Сложная бизнес-логика с архитектурными решениями
Нужно глубокое понимание экосистемы (async Rust, unsafe, FFI)
Команда должна поддерживать код без AI
Оригинал статьи с дополнительными деталями: ifonin.ru/blog/nodejs-rust-claude-code
Комментарии (12)

v_0ver
29.03.2026 16:00У меня был доклад про перенос достаточно оптимизированного cpu-bound кода с Python на Rust. И там был вывод: что можно получить 5x ускорения за счёт 5x времени разработки. Сейчас же с топовыми LLM-ками я получаю 5x ускорение в среднем за $1.5, и почти нулевыми затратами времени.
Мой опыт согласуется с вашими выводами. В принципе тоже самое можно было бы получить и при переносе на C/C++, но к Rust как-то доверия больше =)

IFonin Автор
29.03.2026 16:00Спасибо, интересно что ваши цифры совпадают 5x это уже паттерн, не случайность. Меня кстати к статье и подтолкнул личный опыт: rspack на моём проекте оказался заметно быстрее webpack при одинаковых конфигах и захотелось разобраться почему Rust даёт такой прирост. И про LLM точно подмечено, барьер входа в Rust сейчас кратно ниже. Про доверие к Rust vs C++ согласен memory safety без GC это и есть главный аргумент.

winkyBrain
29.03.2026 16:00Спасибо, интересно что ваши цифры совпадают 5x это уже паттерн, не случайность
это заговор!! а если серьёзно, то тот же тайпскрипт уже вовсю переписывают на rust, потому что rust по дефолту кратно быстрее. и вроде как следующая мажорная версия уже будет на нём. не понятно, в чём ваше открытие

chumurov
29.03.2026 16:00>C/C++, но к Rust как-то доверия больше
Я бы добавил, что rust код разрабу python намного понятнее чем плюсы.

Diamon33
29.03.2026 16:00На своём MacBook M4 я не замечал проблем
Weird flex, but ok.
2026
Я переписал оба скрипта на Rust с помощью AI-ассистента (Claude Code). Получил 5-10x ускорение.
Rust в профильных задачах быстрее, чем Node. Breaking news.
В соседнем комменте Python -> Rust.
Это серьезный пост или троллинг?

chumurov
29.03.2026 16:00Аналогичная история, переписал python скрипт по распаршиванию osm бинарника на rust минут за 15 с помощью кодекса и получил прирост с 30 минут работы до 4х.
PaulIsh
Вы в rust тоже использовали не оптимальный код? Ведь сравниваете заведомо неоптимальный node код с rust? На разных языках сравнивать стоит идеальный код с идеальным, иначе вы не получаете объективной картины.
Попробуйте хотя бы устранить известные недостатки nodejs кода. Наверняка получится также кратное ускорение.
IFonin Автор
Справедливое замечание по методологии. Цель статьи была не в строгом бенчмарке, а в демонстрации разницы "из коробки" что получает разработчик, написав наивный код на обоих языках без специальных оптимизаций.
winkyBrain
из какой коробки?) первые скрипты методами были прямо из Node.js? полагаю, что нет. их писали либо вы, либо чат-бот. то есть вы отдали первый кривой скрипт чат-боту, тот переписал его под rust, потом компилятор rust нашёл ошибки связанные с типами(правда не указано, в чём именно, но видимо в первой попытке чат-бота выдать что-то на rust), они были исправлены - и вуаля, "Галя, у нас победа". А что мешало-то юзать тайпскрипт для строгой системы типов в Node.js, чтобы вообще не столкнуться с такой проблемой?)
sdramare
От использования typescript у вас не исчезнут перфоманс проблемы js типа косвенной адресации в массивах, stop the world из-за gc и отсутствие auto-vectorization
thethee
Для этого нужно знать nodejs, или знать о чем именно просить нейронку. Переписать на Раст проще с точки зрения пользователя, он на слуху, тут и получается plug and play оптимизация производительности.
Профессионал оптимизирует свой код, а обыватель, увы, пойдет по простому пути, получит неоптимальный код, возможно с багами, на другом языке. Вот только если этот неоптимальный код действительно ускоряет, и баги исправимые, то почему бы нет