Порт TypeScript на Rust от Cloudflare: до 8 раз быстрее 7.0

Cloudflare и VoidZero вместе с Максом Швенком (Max Schwenk) из Owner.com 20 октября взяли на себя tsrs, порт компилятора TypeScript на Rust. Проект развивают внутри набора инструментов Oxc и, как сказано в блоге Cloudflare, в тесной связке с командой TypeScript.

По ранним замерам Cloudflare, tsrs до 8 раз быстрее TypeScript 7.0 и расходует примерно на 70% меньше памяти при одинаковом числе воркеров проверки типов. Ускорился и сам TypeScript: 7.1 beta до 2,5 раза быстрее 7.0, и часть этих оптимизаций, по словам авторов поста, пришла в основной код из tsrs. Директор по инжинирингу Cloudflare Кристоф Накадзава написал в X: «Мы не форкаем TypeScript, мы работаем с командой TypeScript, и в результате 7.1 уже примерно в 2,5 раза быстрее».

Та же мысль проходит через весь пост, который Накадзава написал вместе с Бошеном Ченом и Димитрием Митропулосом: «Чтобы было ясно: мы не форкаем TypeScript. Мы считаем, что команда TypeScript должна полностью контролировать дизайн и развитие языка». Объяснение практическое. Некоторые возможности команда TypeScript годами исследует и прототипирует, прежде чем выбрать реализацию, и порт, который не следует этим решениям строго, со временем развалится и станет несовместимым.

Почему не хватило Go

TypeScript 7.0 вышел 8 июля с компилятором, переписанным с JavaScript на Go. В анонсе нативного порта Microsoft обещала сократить большинство сборок в 10 раз: проверка VS Code на 1 505 000 строк кода в её таблице ускорялась с 77,8 до 7,5 секунды. Rust в Microsoft тогда рассматривали, но, как ранее сообщало The New Stack, решили, что воспроизвести архитектуру TypeScript на нём значит получить серьёзные сложности с управлением памятью и совместимостью.

В Cloudflare отвечают, что дело не только в скорости, а главный аргумент - WebAssembly. Программу на Go при сборке в Wasm приходится компилировать вместе с её сборщиком мусора, а модель памяти Rust даёт простой обмен памятью между Wasm-модулем и средой, которая его запускает. Workers давно поддерживают Wasm, а 28 сентября Cloudflare объявила о нативном Rust в Workers через новую цель Emscripten для wasm-bindgen. Компания рассчитывает гонять весь цикл разработки целиком в изолированной песочнице на своей платформе, а через Wasm - в браузере, на встраиваемом устройстве или в IoT-приложении.

Розенвассер из команды TypeScript в обсуждении на Hacker News рассказал, что команда сделала и собственный «вайб-порт» на Rust. По его словам, там сейчас подозревают, что значительная часть прироста скорости объясняется не одним только выбором языка. А кое-что из того, что сделает TS 7.1 быстрее и экономнее, на деле пришло из оптимизаций, найденных в tsrs.

Откуда взялся tsrs

Швенк в своём посте объясняет, с чего всё началось: даже на MacBook за 3 000 долларов с 36 ГиБ памяти инженеры Owner.com не могли параллельно запускать несколько агентов. Однопоточная проверка их проекта Olympus на 37 000 файлов требовала 19 ГиБ памяти и 80 секунд. Его таблица для Olympus выглядит так: tsgo 7.0.2 с четырьмя воркерами проверяет проект за 61,4 секунды при пике 36,0 ГиБ, tsrs 0.14.0 с теми же четырьмя воркерами укладывается в 8,75 секунды и 6,1 ГиБ. Против ночной сборки 7.1 от 29 сентября (43,4 секунды и 28,8 ГиБ) выигрыш сжимается до 5,0x по времени и 4,7x по памяти.

Если грубо поделить 36 ГиБ на пиковое потребление одной проверки и не учитывать систему и редактор, на таком ноутбуке помещается одна полная проверка tsgo с четырьмя воркерами, причём без запаса, и пять проверок tsrs. Пик держится не весь прогон, так что на практике одновременно пройдёт не меньше.

По умолчанию tsrs подбирает конфигурацию под машину: так он берёт больше памяти, зато работает ещё быстрее. У Швенка на Olympus это 16 воркеров, 4,24 секунды и 9,5 ГиБ. В посте Cloudflare предупреждает, что чужие бенчмарки портов TypeScript часто запускают на машинах помощнее и с настройками, отличными от умолчаний TypeScript, и уверяет, что собственные цифры с командой TypeScript сверили на одинаковой конфигурации. Адаптивный режим, 16 потоков против четырёх у tsgo по умолчанию, в таблицах репозитория даёт уже до 16,87x на проекте mui-docs.

Почему именно сейчас, Cloudflare объясняет так: попыток портировать TypeScript было много, но из-за сложности удалась только одна, переход самой команды TypeScript на Go. Теперь передовые модели ИИ проводят крупные порты почти самостоятельно за считаные дни, и в Cloudflare видели уже и «slopfork», и аккуратные порты, и полностью переработанные версии TypeScript на Rust или C++. Похожая история была с Rust-версией Bun, которую в сентябре собрали агентами Claude Code за одиннадцать дней.

Как его будут догонять

Сначала tsrs объединят с tsc-rs Тео Брауна в один пакет, который должен поддерживать все возможности TypeScript. Дальше Cloudflare переносит процесс, которым держит Vinext в синхронизации с Next.js. Каждое утро агент просматривает изменения апстрима, забирает диффы и заводит задачи на всё, что может задеть порт, а каждую ночь матрица совместимости пересобирается прогоном тестов оригинала. Когда тест или задача показывают расхождение, агенты находят изменение в обеих кодовых базах, собирают воспроизведение, переносят тесты и предлагают исправление.

Найденные по пути улучшения производительности Cloudflare обещает отдавать обратно в Go-версию TypeScript. Отличия от оригинала сейчас есть, например порядок вывода диагностик, и их хотят свести к минимуму к стабильному релизу. Команда Oxc уже переделывает кодовую базу ради скорости, памяти и сопровождаемости, а среди возможных интеграций в свой стек Cloudflare называет правила Oxlint, которым нужна информация о типах.

Как попробовать

Экспериментальная версия ставится одной командой, npm install tsrs, и запускается через npx tsrs. Пакет подтягивает нативный бинарник примерно на 35 МБ через необязательные зависимости вида @tsrs/<os>-<arch>. Пакета для Windows в 0.18.0 нет, его настроили к следующему релизу. Флаги --init и --showConfig не поддерживаются. Ошибки в репозиторий можно присылать как issues, а пулл-реквесты закрыты: в README объясняют, что на их ревью не хватает рук.

Для редактора языковой сервер запускается командой tsrs --lsp -stdio: диагностика, подсказки при наведении, переход к определению, переименование, автодополнение с автоимпортом, исправления и форматирование. Настройка для VS Code и Neovim описана в документации проекта.