Hacker News

Tsrs: A Port of TypeScript to Rust

tsrs: TypeScript 컴파일러의 Rust 포트

Cloudflare와 VoidZero가 TypeScript 팀과 협력해 Rust로 TypeScript 컴파일러를 포팅한 실험적 프로젝트 tsrs를 공개했습니다. 같은 수의 타입 검사 작업자를 사용한 초기 벤치마크에서 TypeScript 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 썼으며, Cloudflare는 WebAssembly와 Workers 환경에서 개발 도구를 실행하는 활용도 함께 제시합니다.

에디터 노트

tsrs의 가장 설득력 있는 근거는 모든 TypeScript 프로젝트가 체감할 속도 향상보다 Cloudflare의 Wasm 실행 환경입니다. 글은 같은 작업자 수로 비교했다고 밝히지만, 최대 8배라는 수치는 모든 프로젝트에 적용되는 값이 아니며 댓글에서 나온 VSCode 비교는 TS 7.0 대비 4배, 7.1 대비 3배였습니다. 비교 대상 버전에 따라 결과가 달라집니다. TypeScript 팀원은 tsrs에서 찾은 최적화 일부가 7.1에도 반영됐다고 밝혔습니다. 따라서 성과를 Rust 언어만의 효과로 돌리기는 어렵습니다. 반면 메모리 절감과 Wasm 통합은 Cloudflare가 설명한 실행 환경과 맞닿아 있습니다. Rust 포트의 메모리 모델에 unsafe 추상화가 있다는 댓글의 지적은 별도의 검증 쟁점으로 남지만, 제공된 내용만으로 안전성 문제를 확정할 수는 없습니다. 상위 프로젝트와의 호환성을 자동 테스트하고 차이를 줄이는 유지 관리 계획이 실제로 작동하는지가 장기적인 신뢰도를 가를 것입니다.

AI 요약

Cloudflare와 VoidZero는 Owner.com의 Max Schwenk와 함께 TypeScript 컴파일러를 Rust로 포팅한 tsrs를 개발하고 있습니다. TypeScript 팀과 협력하며 Oxc JavaScript 컴파일러 도구 모음의 일부로 프로젝트를 키우는 중입니다. 기존 TypeScript를 포크해 언어 방향을 바꾸려는 계획은 없습니다. 언어 설계와 동작은 TypeScript 팀이 결정하고, tsrs는 원본 구현과의 호환성을 유지하는 데 초점을 둡니다.

성능과 비교 조건

초기 벤치마크에서 tsrs는 같은 수의 타입 검사 작업자를 설정한 TypeScript 7.0보다 최대 8배 빠르고 메모리를 약 70% 적게 사용했습니다. 비교에는 TypeScript 기본 설정과 같은 조건을 적용했다고 밝혔습니다. TypeScript 7.1 베타도 7.0보다 최대 2.5배 빨라졌으며, 7.1의 일부 최적화는 tsrs에서 발견한 개선점을 TypeScript 쪽에 반영한 결과입니다. tsrs는 기본값으로 머신 종류에 따라 작업 설정을 조정합니다. 이 모드에서는 메모리를 더 쓰는 대신 더 빠르게 동작합니다.

Rust와 WebAssembly

프로젝트의 목적은 컴파일 속도만이 아닙니다. Rust 구현은 WebAssembly(Wasm)로 옮길 때 Go 런타임의 가비지 컬렉터를 함께 포함하지 않아도 됩니다. 글은 Rust의 메모리 관리 방식이 Wasm 호스트와 게스트 사이의 메모리 처리에 더 잘 맞는다고 설명합니다. Cloudflare는 Workers에서 빌드와 배포 도구를 반복 실행하는 환경, 브라우저 안의 격리된 개발 환경, 임베디드 기기와 IoT를 활용 사례로 듭니다. Oxlint의 타입 인식 린트 규칙과 결합하는 방안도 검토하고 있습니다.

호환성과 유지 관리

Cloudflare는 Theo Browne의 tsc-rs와 tsrs를 하나의 패키지로 합치는 작업을 진행 중입니다. 목표는 TypeScript 기능과 Language Server Protocol(LSP), 콘텐츠 매퍼를 지원하는 것입니다. 유지 관리에는 상위 프로젝트 변경을 추적하고 테스트를 다시 돌리는 자동화 절차를 적용할 계획입니다. 현재는 진단 메시지 출력 순서처럼 원본과 다른 동작이 있으며, 안정 버전 전까지 차이를 줄이려 합니다. 성능 개선은 TypeScript의 Go 코드에도 기여해 두 구현이 함께 나아가도록 하겠다고 밝혔습니다.

Hacker News 반응

  • @AbuAssar — VoidZero에 따르면 이 포트는 TS 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 씁니다. 이제 Microsoft는 TypeScript를 Rust로 포팅하는 방안을 진지하게 검토해야 합니다.
    • @tgv — 벤치마크는 대체로 믿기 어렵다는 점은 차치하더라도, 무엇을 위해서죠? TS 컴파일러가 견디기 어려울 만큼 느린가요?
    • @ruther4d — 글에서 말한 목적은 Wasm입니다.
  • @Rapzid — 최대 8배 빠르다는 건 꽤 큰 주장입니다. 무엇을 기준으로 8배 빠르다는 건가요? VSCode를 TS 7.0으로도 10초 안에 컴파일하는데, 이걸 1초 안에 타입 검사하고 컴파일하나요?
    • @magicalist — 정확히는 그렇지 않습니다. 글에 따르면 VSCode 컴파일은 TS 7.1 야간 빌드에서 5.28초, 개발 중인 tsrs에서 1.73초입니다. 약 3배 차이입니다.
  • @DanRosenwasser — TypeScript 팀원입니다. tsrs가 어떻게 빠른지, 어떤 최적화가 안전한지 유지 관리팀과 함께 살펴보고 있습니다. 속도 향상은 언어 선택만으로 설명되지 않는다고 보고 있습니다. TS 7.1의 성능과 메모리 개선 일부도 tsrs에서 발견한 최적화에서 나왔습니다. Wasm과 Oxlint 통합은 Cloudflare의 필요에 잘 맞습니다. 공식 TypeScript 도구도 더 빠르고 효율적으로 만들도록 협력하겠습니다.
    • @lemagedurage — TS 7.1에는 어떤 종류의 최적화가 들어갔나요? 알고리즘 개선인가요, 메모리 관리와 관련 있나요?
    • @DanRosenwasser — 일부 작업을 더 늦게 하거나 적게 수행하도록 바꿨고, 할당 방식과 자료 구조 배치를 조정한 사례도 있습니다.
  • @afdbcreid — Rust 포트는 장기간 살아 있는 객체를 해제하지 않는 arena 방식으로 GC 언어에서 옮길 때 생기는 문제를 피한 것으로 보입니다. Rust에서 이런 방식이 안전하게 작동하는지 흥미롭습니다.
    • @zamalek — 문서 내용을 보면 안전하지 않습니다. 명시적으로 재사용하는 지점에서 객체가 더는 필요 없다는 점을 사람이 증명해야 합니다. arena allocator의 수명을 쓰는 편이 안전하고 간단했을 겁니다.
  • @nsm — TypeScript 컴파일러를 쓰는 목적은 일반 웹 개발자의 반복 작업과 크게 다릅니다. Cloudflare는 수백만 번 실행하면서 비용을 줄이려 합니다. 당장 도구를 바꿀 필요가 있다고 보기는 어렵습니다.
    • @cryptonym — 글을 보면 주요 사용 사례는 AI 에이전트를 위한 샌드박스 환경인 것 같습니다.
  • @egonschiele — 큰 코드베이스에서 TypeScript를 매일 쓰는데 로컬 실행이 느립니다. 다만 AI가 며칠 만에 대규모 포트를 만들 수 있다는 설명은 불편합니다. 에이전트가 코드를 검토하더라도 예상하지 못한 설계 결정을 내릴 때가 있습니다.

원문: Cloudflare Blog / 번역·요약: Trawling