TypeScript,
σε ταχύτητα
Rust.

Ένας compiler για την εποχή των agents

Οι AI coding agents παράγουν κώδικα γρηγορότερα, αλλά πρέπει και να τον ελέγχουν διαρκώς. Σε μεγάλα TypeScript projects, το type checking μπορεί να μετατραπεί σε εμπόδιο για developers, CI runners και agents που δουλεύουν παράλληλα.

Το tsrs είναι ένα experimental port του TypeScript 7 compiler στη Rust. Η Cloudflare και η VoidZero το αναπτύσσουν μαζί με τον Max Schwenk της Owner.com, στο οικοσύστημα Oxc και σε συνεργασία με την ομάδα του TypeScript. Το σημαντικό: δεν επιχειρεί να επινοήσει νέα γλώσσα ή διαφορετικό type system. Στόχος είναι να ακολουθεί τη συμπεριφορά του επίσημου compiler, με μικρότερο κόστος σε χρόνο και μνήμη. [Cloudflare]

Η αλυσίδα είναι σημαντική: ο παλιότερος compiler ήταν γραμμένος σε TypeScript/JavaScript. Το TypeScript 7 είχε ήδη περάσει σε native υλοποίηση Go. Το tsrs μεταφέρει αυτή την υλοποίηση Go στη Rust. Είναι ανεξάρτητο έργο και παράγωγη υλοποίηση, όχι επίσημη κυκλοφορία της Microsoft ούτε fork της κατεύθυνσης της γλώσσας. [Repository]

Πώς μπήκαν οι AI agents στο παιχνίδι

Ο Schwenk περιγράφει ένα backend monolith περίπου 37.000 TypeScript αρχείων. Στο δικό του περιβάλλον, ένας single-threaded έλεγχος με TypeScript 7.0 χρειαζόταν περίπου 80 δευτερόλεπτα και 19 GiB. Όταν πολλά εργαλεία και agents έτρεχαν παράλληλα, το όριο γινόταν η μνήμη, όχι μόνο ο χρόνος αναμονής. [Αφήγηση δημιουργού]

Ο δημιουργός λέει ότι δεν έγραψε ο ίδιος κώδικα για το αρχικό port: καθοδήγησε agents με Claude Opus 5.5 και περισσότερους από 20 subagents. Αυτό είναι δική του περιγραφή, όχι ανεξάρτητος έλεγχος κάθε γραμμής. Η διαδικασία πάντως δεν ήταν «ένα prompt και τελειώσαμε»:

1. Πιστό port του Go compiler, με κοινή δομή και συμπεριφορά.
2. Διαίρεση του έργου σε Rust crates και παράλληλα worktrees.
3. Χρήση των upstream conformance tests για έλεγχο αποτελεσμάτων.
4. Για κάθε optimization: baseline, profiling, μία αλλαγή, σύγκριση output και νέο benchmark.

Ο Schwenk αναφέρει αρχικά 15.197 conformance cases και, μετά τις διορθώσεις, σχεδόν πλήρη αντιστοίχιση σε ένα συγκεκριμένο σύνολο error baselines. Αυτά είναι στοιχεία του έργου. Ένα test suite ενισχύει την εμπιστοσύνη, αλλά δεν αποδεικνύει ότι ένας compiler δεν έχει bugs.

Μέσα στον compiler: τι κάνει κάθε στάδιο

Το port ακολουθεί τη δομή του Go implementation. Ο scanner και ο parser αναλύουν τον κώδικα σε συντακτικό δέντρο (AST). Ο binder καταγράφει declarations και symbols. Ο checker επιλύει τύπους και παράγει diagnostics. Αν δεν έχει ζητηθεί --noEmit, τα στάδια transform και emit μπορούν να παράγουν JavaScript, declarations και source maps. [Porting guide] · [Emit]

Παραλληλισμός χωρίς δωρεάν μνήμη

Parsing και binding γίνονται ανά αρχείο. Στον έλεγχο τύπων, πολλοί checker workers μοιράζονται την εργασία, αλλά διατηρούν και δικό τους checker state και type graph. Περισσότεροι workers μπορεί να μειώσουν τον wall-clock χρόνο, αλλά δεν σημαίνουν αυτόματα μικρότερη συνολική κατανάλωση μνήμης. Το scheduling έχει σημασία, όπως και η σειρά με την οποία ελέγχονται τα αρχεία.

Πού κρύβεται το κέρδος

• Arena allocation: ομαδοποίηση αντικειμένων με συναφείς διάρκειες ζωής, αντί για αμέτρητες μεμονωμένες δεσμεύσεις.
• Πυκνότερα data layouts: μικρότερα headers και λιγότερα bytes ανά αντικείμενο. Σε εκατομμύρια symbols, οι μικρές διαφορές πολλαπλασιάζονται.
• Pointer compression: σε υποστηριζόμενα περιβάλλοντα, ορισμένες αναφορές αποθηκεύονται ως 32-bit offsets σε δεσμευμένη περιοχή μνήμης. Ο δημιουργός αναφέρει 14–15% χαμηλότερο peak memory σε συγκεκριμένα πειράματα, με επιπλέον CPU work.
• Lazy resolution και work stealing: ορισμένα δεδομένα παράγονται όταν χρειαστούν, ενώ διαθέσιμοι workers μπορούν να αναλάβουν εκκρεμή αρχεία. Αυτές οι επιλογές συνδέονται με performance modes και δεν είναι όλες ενεργές εξ ορισμού στο 0.20.

Τα επιμέρους ποσοστά προέρχονται από διαφορετικές δοκιμές και αναθεωρήσεις. Δεν προστίθενται μεταξύ τους, ούτε αποτελούν υπόσχεση για κάθε project.

Το «έως 8×» θέλει αστερίσκο

Η Cloudflare αναφέρει έως 8 φορές ταχύτερο type checking και περίπου 70% λιγότερη μνήμη σε σύγκριση με TypeScript 7.0, με ίδιο αριθμό type-check workers. Αυτό είναι εταιρικό benchmark και αφορά συγκεκριμένα workloads, όχι εγγύηση ότι κάθε build θα γίνει οκτώ φορές γρηγορότερο. [Μεθοδολογικό πλαίσιο Cloudflare]

Η σύγκριση επίσης αλλάζει όταν χρησιμοποιηθεί νεότερο baseline. Το TypeScript 7.1 beta έχει δικές του βελτιώσεις και μέρος τους ωφελήθηκε από optimizations που συνδέονται με το tsrs. Η σύγκριση μόνο με το 7.0 μπορεί να μεγαλοποιήσει την απόσταση από το πιο πρόσφατο Go compiler. [Microsoft: TypeScript 7.1 beta]

Ανεξάρτητη δοκιμή: το codebase του VS Code

Σε ανεξάρτητο πείραμα με Linux VM 4 vCPUs, ίδιο αριθμό τεσσάρων checker threads και --noEmit, οι διάμεσοι χρόνοι ήταν:

Στο ίδιο πείραμα, το peak RSS για το VS Code ήταν περίπου 5.542 MiB στο 7.1 beta και 1.801 MiB στο tsrs 0.18. Σε τέσσερα projects, ο συγγραφέας μέτρησε περίπου 3,9–4,9× διαφορά έναντι 7.1 beta. Το 0.18 όμως είχε διαφορετικά defaults από το 0.20, οπότε οι αριθμοί δεν μεταφέρονται αυτόματα στη σημερινή έκδοση. [Ανεξάρτητη μεθοδολογία και μετρήσεις]

Επιπλέον, το --noEmit μετρά έλεγχο τύπων χωρίς παραγωγή αρχείων. Δεν είναι συνολικός χρόνος bundling, emit ή deploy. Για αξιόπιστη σύγκριση κράτησε ίδια έκδοση project, ίδια flags, ίδιο αριθμό workers, ίδιο μηχάνημα και σύγκρινε τόσο χρόνο όσο και peak RSS.

Default εναντίον --fast: η αλλαγή που μετράει

Η έκδοση 0.20.0, δημοσιευμένη στις 26 Οκτωβρίου, στοχεύει στο TypeScript 7.1 beta. Το default χρησιμοποιεί τέσσερις checkers και συμπεριφορά προσανατολισμένη στην αντιστοίχιση με το Go compiler. Οι πιο επιθετικές βελτιστοποιήσεις μεταφέρθηκαν πίσω από το --fast. [Release notes 0.20.0]

Αν το CI σου αντιμετωπίζει το exit code ως κριτήριο αποτυχίας ή κάνει snapshot ακριβές κείμενο σφάλματος, αυτή η διαφορά δεν είναι λεπτομέρεια. Χρησιμοποίησε πρώτα default mode για σύγκριση συμπεριφοράς και μέτρησε το fast mode ξεχωριστά.

Γιατί Rust; Και γιατί WebAssembly;

Η Rust επιτρέπει έλεγχο του layout και της διαχείρισης μνήμης, αλλά το κέρδος έρχεται από συγκεκριμένες σχεδιαστικές αποφάσεις, όχι μαγικά από τη γλώσσα. Η πρώτη υλοποίηση του Schwenk, όπως γράφει, ήταν ταχύτερη αλλά χρησιμοποιούσε περισσότερη μνήμη πριν από τη βελτιστοποίηση.

Το δεύτερο κίνητρο είναι το WebAssembly. Η Cloudflare θέλει έναν compiler που μπορεί να ενσωματωθεί σε browser ή sandboxed περιβάλλοντα όπως Workers. Το Rust/Wasm μοντέλο αποφεύγει την ανάγκη να μεταφερθεί μαζί του το Go garbage collector runtime. Αυτό είναι αρχιτεκτονικό πλεονέκτημα για φορητότητα και footprint, όχι απόδειξη ότι κάθε browser workload θα είναι ταχύτερο. Υπάρχει πακέτο @tsrs/wasm, αλλά οι δυνατότητές του πρέπει να ελεγχθούν ανά έκδοση και περιβάλλον.

Συμβατότητα: η ταχύτητα δεν αρκεί

Το tsrs 0.20 έχει προχωρήσει πέρα από το αρχικό project μόνο για type checking. Τα release notes περιγράφουν δυνατότητες language server και πλατφόρμες macOS, Linux και Windows x64, ενώ ο compiler υποστηρίζει και emit. Ωστόσο, Windows watch mode δεν υποστηρίζεται ακόμη στην έκδοση 0.20. Το παλιότερο «δεν υπάρχει watch ή language server» δεν είναι σωστή γενική περιγραφή της τρέχουσας έκδοσης. [Compatibility matrix]

• --init, --showConfig και --generateTrace δεν υποστηρίζονται στη συγκεκριμένη έκδοση. Το --locale αγνοείται.
• Το language-server mapper execution παραμένει μη υλοποιημένο.
• Η 0.20 στοχεύει στο TypeScript 7.1 beta. Ένα project σε TypeScript 5 ή 6 μπορεί πρώτα να χρειάζεται migration των ρυθμίσεών του.
• Το --fast μπορεί σε συγκεκριμένες περιπτώσεις να δώσει διαφορετικά diagnostics ή exit codes. Η συμβατότητα πρέπει να ελέγχεται στο δικό σου codebase.

Το έργο διανέμεται με Apache 2.0. Ως παράγωγο έργο διατηρεί upstream attribution και notices. Αυτό δεν το καθιστά επίσημο προϊόν ή endorsement της Microsoft.

Δοκίμασέ το χωρίς να σπάσεις το CI

Για αναπαραγώγιμο πείραμα, κάνε pin την έκδοση και τρέξε αρχικά έλεγχο χωρίς emit. Οι εντολές προϋποθέτουν υπάρχον project και tsconfig.json:

# Εγκατάσταση της συγκεκριμένης beta έκδοσης
npm install --save-dev [email protected]

# Έλεγχος τύπων, χωρίς παραγωγή αρχείων
npx tsrs -p . --noEmit

# Ξεχωριστή δοκιμή του performance mode
npx tsrs -p . --noEmit --fast

Για να συγκρίνεις με τον επίσημο compiler, χρησιμοποίησε το αντίστοιχο [email protected] σε ξεχωριστό δοκιμαστικό environment ή pinned dependency. Κράτησε ίδια tsconfig, flags και αριθμό checkers. Μην αλλάζεις ταυτόχρονα έκδοση TypeScript, flags και hardware, γιατί μετά δεν ξέρεις τι προκάλεσε τη διαφορά. [Οδηγίες χρήσης]

Μια λογική διαδρομή υιοθέτησης

1. Baseline: κατέγραψε χρόνο, peak RSS και diagnostics του επίσημου compiler.
2. Shadow run: πρόσθεσε το tsrs ως δεύτερο, μη-blocking CI job, με pinned έκδοση.
3. Parity: σύγκρινε error codes, θέσεις, κείμενα, exit status και, αν χρησιμοποιείς emit, τα παραγόμενα αρχεία.
4. Performance test: μέτρησε default και --fast ξεχωριστά, με αρκετές επαναλήψεις.
5. Απόφαση: κράτησε τον επίσημο compiler ως gate μέχρι η συμπεριφορά του tsrs να αποδειχθεί αξιόπιστη για το δικό σου project.

Το συμπέρασμα

Το tsrs είναι από τα πιο ενδιαφέροντα πειράματα της νέας γενιάς developer tooling: ένας compiler που γεννήθηκε με AI-assisted porting και προσπαθεί να κάνει γρηγορότερο τον ίδιο κύκλο ανάπτυξης που χρειάζονται οι AI agents.

Για μεγάλα monorepos, τα αποτελέσματα σε χρόνο και μνήμη δικαιολογούν μια σοβαρή δοκιμή. Για μικρά projects, το κέρδος μπορεί να μην αξίζει ένα επιπλέον κομμάτι υποδομής. Η έξυπνη κίνηση σήμερα είναι απλή: μέτρα το στο δικό σου codebase, παράλληλα με τον επίσημο compiler, πριν του δώσεις τα κλειδιά του CI.