TypeScript Go’dan Rust’a mı geçiyor? tsc-rs ve tsrs gerçekte neyi değiştiriyor?

WBK AI · Dün 10:45 da

Read this article in English →

Bir satır kodu değiştirdiniz; tarayıcıdaki sonuç hazır, ama terminal hâlâ tip denetiminin bitmesini bekliyor. Büyük bir TypeScript projesinde derleyici performansı tam da burada önem kazanıyor. Go’ya taşınan resmî derleyicinin ardından şimdi Rust portları konuşuluyor. Better Stack’in “TypeScript Got Ported To Rust… And It’s 3x Faster Than Go” başlıklı videosu da bu tartışmayı gündeme getiriyor.

Fakat haberi “Microsoft, Go’yu bırakıp Rust’a geçiyor” diye okumak yanlış. Rust’a taşınan şey TypeScript dilinin kendisi değil, derleyicinin bağımsız uygulamaları. Microsoft’un Go tabanlı derleyicisi, Theo Browne’ın tsc-rs projesi ve Oxc çatısı altındaki tsrs aynı hikâyenin farklı parçaları. Hangisini konuştuğumuz, hem hız rakamını hem de geçiş kararını değiştiriyor.

Öne çıkanlar

Microsoft’un resmî TypeScript 7 derleyicisi Go tabanlı. İncelenen kaynaklarda Rust’a geçiş kararı yok.
tsc-rs ve tsrs, TypeScript davranışını Rust’ta korumayı amaçlayan ayrı portlar. Cloudflare, iki çalışmayı birleştirmek için Theo Browne ile çalıştığını duyurdu.
“3 kat” veya “8 kata kadar” farklı proje, sürüm ve ayarların sonucu olabilir; her projeye uygulanacak sabit kazançlar değiller.
Rust tarafındaki önemli fırsat yalnızca hız değil: bellek kullanımı ve WebAssembly ile tarayıcıya taşınabilen geliştirme araçları da işin içinde.
Denemeye değer; mevcut CI denetimini hemen kaldırmaya değil.

İçindekiler

TypeScript’in “temel dili” gerçekten değişiyor mu?

TypeScript yazarken kullandığınız interface, generics veya union türleri Go’ya da Rust’a da dönüşmüyor. Değişen, bu kodu okuyan, tür ilişkilerini denetleyen ve gerektiğinde JavaScript çıktısı üreten programın hangi dille yazıldığı. Dil ile o dili işleyen aracın uygulama dili aynı şey değil.

Microsoft, Mart 2025’te yerel derleyici çalışmasını duyurdu; Mayıs 2025’te npm üzerinden önizlemeyi açtı. Go seçimi, yerel makine koduna derlemenin yanında paralel çalışmadan da yararlanmayı sağladı. O dönemde paylaşılan yaklaşık 10 katlık kazanç, önceki JavaScript tabanlı uygulamayla yapılan karşılaştırmaydı. Bugün Rust portlarının Go uygulaması karşısındaki iddialarıyla aynı ölçüm değil. Bu ilk geçişin arka planını TypeScript 7 ve Go derleyicisi yazımızda ele almıştık.

Bu değişim, uygulamanızın tarayıcıda Rust olarak çalışması anlamına da gelmiyor. Daha hızlı tip denetimi geliştiricinin beklemesini azaltabilir; kullanıcıya gönderilen uygulamanın otomatik olarak üç kat hızlanacağını söylemez.

tsc-rs ve tsrs: Benzer isimler, ayrı projeler

ts-rust, diğer adıyla tsc-rs, Theo Browne’ın TypeScript derleyicisini, tip denetleyicisini ve dil sunucusunu Rust’a taşıma çalışması. npm paketi tsc-rs. Projenin README’si bunu Go tabanlı uygulamanın doğrudan portu olarak tanımlıyor; amaç yeni bir TypeScript tasarlamak değil, mevcut davranışı daha hızlı bir araçta sürdürmek. Aynı belge, bunun erken bir sürüm olduğunu ve bilinen sorunlar bulunduğunu da belirtiyor.

tsrs ise Max Schwenk’in çalışmasından doğan, Cloudflare ve VoidZero’nun Oxc araç zinciri içinde geliştirdiği Rust portu. Cloudflare’ın 20 Ekim 2026 tarihli duyurusu, TypeScript ekibiyle yakın işbirliğini özellikle vurguluyor. Dilin tasarım yönünü TypeScript ekibinin belirlemeye devam etmesini istiyorlar. Proje deposu da Microsoft tarafından desteklenen veya onaylanan resmî ürün olmadığını açıkça yazıyor.

Microsoft’un Go derleyicisi ile bağımsız Rust portları tsc-rs ve tsrs arasındaki ilişki.

Aynı TypeScript kodunu işleyen farklı derleyiciler. Cloudflare’ın duyurduğu birleşme çalışması, iki Rust paketini bugün kendiliğinden tek ürün yapmıyor. Görsel: DevOpen; kaynaklar: Microsoft, pingdotgg, Oxc ve Cloudflare.

Burada bir de birleşme haberi var: Cloudflare, tsc-rs ile tsrs çalışmalarını tek pakette buluşturmak için Theo Browne ile çalıştığını duyurdu. Bunu tamamlanmış bir birleşme ya da Microsoft’un derleyicisini Rust’a devretmesi gibi sunmak doğru değil. Paketlerin sürüm notları, destekledikleri özellikler ve uyumluluk kayıtları ayrı ayrı kontrol edilmeli.

“Go’dan 3 kat hızlı” derken ne ölçülüyor?

Bir benchmark başlığı, ölçümün sonucu kadar kapsamını da anlatmalı. Videonun başlığındaki üç katlık iddiayı bütün TypeScript projeleri için bir garanti gibi okuyamayız. Aynı şekilde Cloudflare, duyurusunda aynı sayıda tip denetleyici çalışanıyla yapılan erken testlerde TypeScript 7.0’a göre 8 kata kadar hız ve yaklaşık yüzde 70 daha az bellek kullanımı bildirdi. Bu rakamlar Cloudflare’ın sonuçları; DevOpen tarafından yapılmış bağımsız ölçümler değil.

Üstelik aynı duyuru, TypeScript 7.1 beta tarafının da 7.0’a göre bazı testlerde 2,5 kata kadar hızlandığını söylüyor. Yani “Go sürümü” bile sabit bir hedef değil. Yeni Go derleyicisini eski sürümle karşılaştırmak başka; güncel Rust portuyla aynı kaynak revizyonuna yakın Go sürümünü karşılaştırmak başka. İki farklı karşılaştırmadan gelen çarpanları birbiriyle çarpmak da anlamlı değil.

Asıl bakılması gerekenler daha az gösterişli ama daha yararlı: Aynı tsconfig.json mu kullanılmış? skipLibCheck aynı mı? Çıktı üretimi açık mı, yalnızca tip denetimi mi yapılıyor? Kaç CPU çekirdeği ve kaç denetleyici kullanılmış? Bellekte tutulan ek önbellekler süreyi kısaltırken tepe bellek tüketimini artırmış mı?

Derleyici hız testlerini değerlendirirken sürüm, iş yükü, kaynak, önbellek ve doğruluğu kontrol etme rehberi.

Bir hız iddiasını okumak için kontrol listesi. Bu görsel benchmark sonucu değil; proje depolarında açıklanan yöntemlerden hazırlanmış bir değerlendirme rehberi.

tsrs deposu, varsayılan modla --fast modunu ayrıca ayırıyor. Hızlı mod, makineye ve projeye göre denetleyici sayısını uyarlıyor ve ek optimizasyonlar açıyor. Bu sonuç değerlidir; yalnızca varsayılan ayarlarla birebir aynı deneymiş gibi sunulmamalı. En önemlisi de hızlı biten aracın aynı hataları yakaladığından emin olmak. Daha az denetim yapan bir komutun daha çabuk bitmesi tek başına başarı sayılmaz.

Rust’ın cazibesi yalnızca kronometrede değil

Cloudflare’ın Rust gerekçesinde WebAssembly önemli bir yer tutuyor. Go kodunu Wasm’a derlediğinizde Go çalışma zamanı ve çöp toplayıcısı da işin parçası oluyor. Rust’ın bellek yönetimi modeli ise aynı türden bir çöp toplayıcı çalışma zamanını beraberinde taşımayı gerektirmiyor. Bu, özellikle bellek sınırı dar ortamlarda farklı tasarım seçenekleri sunuyor; her Rust programının her Go programından küçük olacağı anlamına gelmiyor.

Tarayıcı içinde çalışan bir editör, çevrim içi kod deneme alanı veya yalıtılmış bir geliştirme ortamı düşünün. Tip denetleyicisini bu ortamın içine alabilmek, her değişiklikte uzak bir sunucuya başvurmayı azaltabilir. tsrs tarafında bunun için @tsrs/wasm paketi ve bir tarayıcı deneme alanı bulunuyor. Yine de Wasm desteği, bütün Node API’lerinin veya editör entegrasyonlarının tarayıcıda eksiksiz çalıştığı anlamına gelmez; hedef ortam ve desteklenen özellikler ayrıca incelenmeli.

Buradaki ilginç taraf “Rust, Go’yu yendi” tartışmasından daha somut: Aynı tip denetimi daha az kaynakla nerelere taşınabilir? Cloudflare’ın bu projeyle ilgilenmesinin arkasında da Workers üzerinde ve tarayıcıda çalışabilen geliştirme ortamları var.

Mevcut denetimi bozmadan nasıl denersiniz?

İlk denemeyi ayrı bir dalda yapın. Kullandığınız resmî TypeScript sürümünü ve mevcut kilit dosyanızı kaydedin; aşağıdaki kurulum seçilen Rust paketlerinin sürümünü tam olarak sabitler. Paket sürümleri ve desteklenen platformlar değişebildiği için önce ilgili sürüm notlarına bakın.

Kod:

# Ayrı bir deneme dalında
npm install --save-dev --save-exact tsc-rs tsrs

# Aynı proje; önce mevcut resmî derleyici
npx --no-install tsc --project tsconfig.json --noEmit

# Ardından Rust portları
npx --no-install tsc-rs --project tsconfig.json --noEmit
npx --no-install tsrs --project tsconfig.json --noEmit

Bu komutlar bir performans ölçümü değil, aynı projede başlangıç karşılaştırması. Çalışma sürelerinin yanında çıkış kodunu, hata kodlarını, dosya ve konum bilgilerini karşılaştırın. Yalnızca “üçü de sıfır hata verdi” demek yerine, bilinen bir tip hatasını yakaladıklarını da doğrulayın. İlk çalışmayı sonraki çalışmalardan ayrı kaydedin; ölçümleri aynı makinede birkaç kez tekrarlayın.

Varsayılan davranışı gördükten sonra tsrs --fast gibi seçenekleri ayrı bir deney olarak değerlendirebilirsiniz. Uygulamanız project references, declaration çıktısı, özel dönüşümler veya TypeScript’in programatik API’sine bağlı araçlar kullanıyorsa yalnızca --noEmit sonucuyla karar vermeyin. Editörde yeniden adlandırma, tanıma gitme ve tamamlama gibi günlük işler de geçiş testinin parçası. tsrs uyumluluk belgesi ve tsc-rs deposundaki bilinen sorunlar bu yüzden önemli.

Geçmek için doğru zaman mı?

Tip denetimi CI sürenizin ciddi bir bölümünü alıyorsa, denemek için iyi bir nedeniniz var. Fakat birkaç saniyelik kazanç için çalışan bütün araç zincirini değiştirmek zorunda değilsiniz. Rust portunu önce mevcut denetimin yanında, sonucu gözlemlediğiniz ek bir adım olarak çalıştırın. Beklenen hatalar, build çıktıları ve editör davranışı doğrulanmadan resmî kontrolü kaldırmayın.

Bugünkü haberin özü şu: TypeScript Go’dan vazgeçmiyor; Go ile elde edilen yerel derleyici yaklaşımının yanında, Rust ile geliştirilen alternatifler olgunlaşmaya çalışıyor. Bu çalışmaların optimizasyonları resmî projeye de geri dönebilir; Cloudflare duyurusunda bunun örnekleri bulunduğunu belirtiyor. Geliştirici için iyi sonuç, bir dilin diğerini yenmesi değil, aynı doğrulukla daha az beklemek.

Kaynaklar ve okuma notu

Video bu yazının çıkış noktasıdır. Videonun tam dökümü doğrulanamadığı için konuşmacıya ayrıntılı ifadeler atfedilmedi; teknik değerlendirme aşağıdaki birincil kaynaklara dayanıyor. Performans rakamları kaynakların kendi bildirimleri, kurulum örnekleri ise bu yazı için çalıştırılmış bir proje testi değil. Depo belgeleri zamanla güncellenebilir.

TypeScript Go’dan Rust’a mı geçiyor? tsc-rs ve tsrs gerçekte neyi değiştiriyor?

WBK AI

TypeScript’in “temel dili” gerçekten değişiyor mu?​

tsc-rs ve tsrs: Benzer isimler, ayrı projeler​

“Go’dan 3 kat hızlı” derken ne ölçülüyor?​

Rust’ın cazibesi yalnızca kronometrede değil​

Mevcut denetimi bozmadan nasıl denersiniz?​

Geçmek için doğru zaman mı?​

Kaynaklar ve okuma notu​