- Echipa TypeScript a ales un port pentru a rescriere completă, astfel încât mesajele de eroare și semantica să rămână identice.
- Colectarea gunoiului și închiderile de primă clasă ale Go au fost esențiale pentru gestionarea structurilor de date complexe ale compilatorului.
- Verificatorul de împrumuturi al lui Rust ar fi forțat soluții manuale pentru referințele circulare, adăugând o complexitate inutilă.
- Go a oferit generare de cod nativ matur și concurență cu memorie partajată fără niciun efort suplimentar.
Când echipa TypeScript a decis să-și porteze compilatorul într-un limbaj nou, aveau un obiectiv clar: să mențină totul funcțional exact ca înainte. Aceasta însemna păstrarea mesajelor de eroare și a semanticii exacte pe care dezvoltatorii s-au bazat ani de zile. Potrivit lui Anders Hejlsberg, arhitectul principal, o rescriere completă era exclusă, deoarece ar risca să întrerupă compatibilitatea inversă. În schimb, au optat pentru un port - iar această decizie a pregătit scena pentru o alegere surprinzătoare: să renunțe la Rust.
Portarea avea nevoie de un limbaj care să poată gestiona structurile interne complexe ale compilatorului fără a impune modificări majore. Echipa și-a dat seama rapid că colectarea gunoiului și închiderile de primă clasă nu erau negociabile. Go oferă ambele funcționalități gata de utilizare, alături de generarea de cod nativ matur și concurența cu memorie partajată pe fiecare platformă majoră. Rust, pe de altă parte, ar fi necesitat soluții manuale semnificative, în special pentru structurile de date circulare ale compilatorului.
De ce să renunți la rugină pentru port
Hejlsberg a explicat că compilatorul este plin de pointeri părinte, tipuri recursive și simboluri care se referă între ele. Acestea creează referințe circulare care sunt naturale într-un limbaj cu colectare a gunoiului. Runtime-ul Go gestionează acest lucru fără probleme, permițând echipei să se concentreze pe port în loc să lupte cu limbajul. Verificatorul de împrumuturi al Rust, deși puternic pentru siguranța memoriei, pur și simplu nu permite această formă fără a recurge la cod nesigur sau trucuri de numărare a referințelor. Acest lucru ar adăuga complexitate și risc, fără o recompensă clară.
Comparând cele două limbaje, echipa nu a găsit niciun avantaj semnificativ în generarea de cod sau concurența pentru Rust. Generarea de cod nativă a Go este deja matură, iar goroutine-urile sale oferă un model simplu și eficient pentru execuția concurentă. Performanța Rust ar putea fi puțin mai bună în unele cazuri limită, dar efortul suplimentar necesar pentru ca compilatorul să funcționeze cu regulile sale de proprietate nu era justificat. Portarea trebuia să fie pragmatică, nu o demonstrație a caracteristicilor limbajului.
Compatibilitate și semantică: prioritatea principală
Principalul factor determinant din spatele portării a fost menținerea unui comportament identic. Dezvoltatorii se bazează pe mesajele de eroare ale TypeScript pentru a depana codul, iar orice modificare le-ar putea perturba fluxurile de lucru. Prin portarea la Go, echipa a putut reutiliza logica și structurile de date existente, asigurându-se că rezultatul rămâne compatibil octet cu octet. Această abordare reduce, de asemenea, riscul introducerii unor erori subtile pe care le-ar putea aduce o rescriere.
Colectarea gunoiului în Go a fost un factor cheie. Graficul intern de noduri și referințe al compilatorului este puternic interconectat, iar gestionarea manuală a memoriei ar fi un coșmar. Cu Go, echipa poate aloca și elibera memorie automat, permițându-le să se concentreze asupra logicii compilatorului. Închiderile de primă clasă au facilitat, de asemenea, implementarea diferitelor pase și transformări efectuate de compilator, deoarece acestea pot capta contextul în mod natural.
Verificatorul de împrumuturi al lui Rust: Un factor decisiv
Verificatorul de împrumuturi din Rust este conceput pentru a preveni concurența datelor și erorile de memorie în timpul compilării, dar vine cu reguli stricte. Structurile de date ale compilatorului TypeScript sunt pline de cicluri și referințe partajate, pe care verificatorul de împrumuturi le respinge, cu excepția cazului în care utilizați blocuri nesigure sau Rc/RefCell. Hejlsberg a remarcat că acest lucru ar forța soluții manuale pentru fiecare structură de date circulară, adăugând o structură standard și îngreunând întreținerea codului. Nu exista niciun avantaj de generare a codului sau de concurență care să justifice această muncă suplimentară.
În cele din urmă, alegerea a fost clară. Go a oferit echilibrul potrivit între simplitate, performanță și compatibilitate. Portarea este acum în curs de desfășurare, iar echipa este încrezătoare că va oferi aceeași experiență TypeScript cu un compilator mai rapid și mai eficient. Pentru dezvoltatori, aceasta înseamnă că nu vor exista surprize - doar același instrument fiabil pe care l-au folosit întotdeauna, rulând pe o bază mai modernă.
Având în vedere toate aspectele, decizia de a alege Go în locul Rust pentru portarea TypeScript se reduce la o inginerie practică. Nevoia de colectare a gunoiului, închideri de primă clasă și gestionarea perfectă a referințelor circulare au făcut din Go alegerea ideală. Garanțiile de siguranță oferite de Rust sunt impresionante, dar vin cu un cost pe care echipa TypeScript nu a fost dispusă să-l plătească. Rezultatul este o portare care păstrează tot ceea ce dezvoltatorii iubesc la TypeScript, punând în același timp bazele pentru îmbunătățiri viitoare.
