Ein GitHub-Projekt namens ts-rust macht seit ein paar Tagen in Entwicklerkreisen die Runde. Es portiert den von Microsoft in Go neu geschriebenen TypeScript-Compiler samt Typprüfer und Language Server (LSP) komplett nach Rust; das Kommandozeilen-Tool heißt tsc-rs. Der Maintainer pingdotgg schreibt in der Projektbeschreibung unverblümt: Der gesamte Implementierungscode wurde von einem großen Sprachmodell erzeugt, er selbst habe keine einzige Zeile davon gelesen.
Das Projekt ist an eine bestimmte Upstream-Version von microsoft/typescript-go fixiert, entsprechend TypeScript 7.1.0-dev. Laut Projektbeschreibung haben 181.711 aus der Go-Version übernommene Tests allesamt bestanden, und in den realen Projekten, die der Autor getestet hat, liegt die Kompatibilität bei 100 Prozent. Das Repository steht unter MIT-Lizenz, behält aber die Apache-2.0-Hinweise von TypeScript und die BSD-3-Clause-Hinweise der Go-Standardbibliothek bei und hat aktuell über 600 Stars.
Zwei Modell-Ansätze
Der Autor testete zunächst mit OpenAIs GPT-5.6 Sol und GPT-6 Astra, die API-Kosten überstiegen 400.000 US-Dollar, dabei entstanden rund 1,3 Millionen Zeilen Rust-Code, die Kompatibilität blieb aber bei 84 Prozent stehen. Danach wechselte er zu Claude Opus 5.5 und begann von vorn: Nach 10 Stunden gab es ein lauffähiges v0, die Gesamtkosten über zwei Wochen lagen bei rund 24.047 US-Dollar.
"I've never read a line of this code."
(Ich habe keine einzige Zeile dieses Codes gelesen.)
Bei der Performance nahm der Autor sein eigenes Projekt T3 Code als Maßstab: tsc-rs braucht für die Typprüfung 7,25 Sekunden, die Go-Version tsc 7 benötigt 16,10 Sekunden – 2,22-mal schneller. Bezogen auf die JavaScript-Version tsc 6 als Basislinie ist tsc 7 7,1-mal und tsc-rs 11,4-mal schneller. Diese Zahlen stammen allesamt aus eigenen Tests des Autors, eine unabhängige Reproduktion gibt es bisher nicht, und weder OpenAI noch Anthropic haben sich öffentlich zu diesem Vergleich geäußert.
Einordnung neben ähnlichen Projekten
Große Sprachmodelle für umfangreiche Code-Migrationen gab es dieses Jahr schon mehrfach öffentlich zu sehen. GitHub hatte zuvor offengelegt, mit Copilot eine eigene Runtime in 830.000 Zeilen Rust umgeschrieben zu haben; Mistral migrierte mit einem Agenten 40.000 Zeilen Fortran 77 nach C++. Gemeinsam ist diesen Projekten eine bereits vorhandene, breit abdeckende Testsuite, die als Schiedsrichter fungiert.
ts-rust folgt demselben Muster. Microsofts Go-Portierung war selbst eine dateiweise, geradezu „abschreibende“ Neuimplementierung, und die Testfälle wurden dabei gleich mit übernommen – das gibt dem Modell ein fast vollständig eindeutiges Ziel: Zehntausende Tests, bestanden oder nicht. Der Abstand zwischen den beiden Modellen wird bei solchen Aufgaben mit klarem Ziel und sofortigem Feedback stark verstärkt. Ob dieser Vergleich auch für Business-Code mit vagen Anforderungen und ohne Testabsicherung gilt, ist derzeit offen.
Bekannte Schwachstellen
Die Projektbeschreibung nennt vier Einschränkungen: In Monorepos, in denen dieselbe Datei über mehrere Pfade erreichbar ist, können mehr Ausgabedateien entstehen als bei tsc; bei inkrementellen Builds mit tsc -b können veraltete oder fehlende Artefakte gelesen werden; in langen Editier-Sessions wächst der Speicherverbrauch langsam, etwa 20 MB je 1.000 Änderungen; die angezeigte Versionsnummer ist die 7.1.0-dev zum Zeitpunkt der Portierung, nicht die npm-Version.
Der Autor positioniert das Projekt als frühe Version. Für Teams, die es ausprobieren wollen, ist es der sicherere Weg, tsc-rs und das offizielle tsc parallel in der CI laufen zu lassen und die Diagnoseausgaben zu vergleichen; es direkt als Ersatz für die Produktions-Build-Kette einzusetzen, ohne dass jemand den Code geprüft hat, ist ein Risiko, das jedes Team selbst abwägen muss.
Quellen: Projektbeschreibung von ts-rust, CocoLoop, Hacker-News-Diskussion; die Projektbeschreibung wurde gegen Testanzahl, API-Kosten sowie Zeit und Faktor des T3-Code-Benchmarks abgeglichen.