TypeScript 7.0 RC: Go ile Yeniden Yazıldı, 10 Kat Hızlandı
Açık konuşayım: TypeScript tarafında sessiz sakın ama baya büyük bir iş yapılmış. Microsoft’un duyurduğu TypeScript 7.0 RC, öyle sıradan bir sürüm atlaması değil; derleyicinin altı üstü resmen elden geçmiş. Bootstrapped JavaScript çıktısı yerine artık Go ile yazılmış native bir ikili dosya çalışıyor. Sonuç? Çoğu projede yaklaşık 10 kat hız artışı. Evet, kulağa iddialı geliyor.
Şimdi sız de “yine mi hız vaadi” diyebilirsiniz. Haklısınız, ilk bakışta öyle dürüyor. Ama burada işin aslı biraz daha sade: native kod var, üstüne bir de paylaşımlı bellekle paralellik eklenmiş (yanı tek çekirdeğe abanıp kalmıyor), dolayısıyla JavaScript’in tek-thread yapısından çıkınca çok çekirdekli makineler nihayet işe yarar hâle geliyor.
Bunu biraz açayım.
Neden Go? Neden Rust ya da C++ Değil?
Bak şimdi, Bu soru ilk duyurudan beri dönüp dürüyor. Anders Hejlsberg’in anlattığı şey net: mevcut TypeScript kod tabanının yapısını olabildiğince korumak için Go en mantıklı seçenek olmuş. Rust’ın ownership modeli var ya, hani o disiplinli tarafı, derleyicinin grafik tabanlı veri yapılarıyla pek iyi anlaşmıyor gibi; özellikle döngüsel referanslar işin içine girince olay biraz karışıyor.
Go’nun garbage collector’lı yapısı işe mevcut algoritmaların doğrudan taşınmasına izin vermiş. Yanı sıfırdan yazım değil, daha çok methodical port. Bu küçük detay gibi görünüyor ama değil. Çünkü sıfırdan başlasalardı semantik farklar çıkabilirdi, yıllardır biriken ortam de ufaktan kırılmaya başlardı (evet, doğru duydunuz)
“Type-checking logic is structurally identical to TypeScript 6.0.” — Bu cümle aslında lafı fazla uzatmadan her şeyi söylüyor: davranış aynı kalıyor, hız değişiyor.
Native + Paylaşımlı Bellek = Asıl Olay
Sahada sık gördüğüm bir şey var: büyük monorepo’larda tsc --build komutu CI tarafında 4-5 dakikayı rahat buluyor, geliştirici makinesinde de editörün nefesi kesiliyor (özellikle proje şiştikçe daha da belli oluyor). Çünkü Node.js süreci çoğu zaman tek bir CPU çekirdeğine yükleniyor, diğer çekirdekler işe kenarda boş boş bekliyor. Go’ya geçişle birlikte type checker artık paralel çalışabiliyor; 16 çekirdekli iş istasyonlarında farkın hissedilmemesi zor.
Şimdi gelelim işin can alıcı noktasına.
Nasıl Kurulur ve Denenir?
Kurulum tarafı şaşırtıcı derecede düz. npm üzerinden RC etiketiyle çekiyorsunuz:
npm install -D typescript@rc
npx tsc --version
# Version 7.0.1-rcYanı ekstra bir konfigürasyon oyununa gerek yok. tsconfig.json aynı kalıyor, CLI argümanları aynı, çıktı yine aynı. Sadece çalışma süresi kısalıyor, hepsi bu. VS Code içinde editör deneyimini yoklamak istiyorsanız TypeScript Native Preview uzantısını kurmanız yeterli; bu uzantı LSP (Language Server Protocol) tabanlı çalıştığı için Neovim, Zed, hatta Copilot CLI gibi araçlarla da kullanılabiliyor. Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor? yazımızda bu konuya da değinmiştik.
6.0 ile Yan Yana Çalıştırmak
Bak şimdi, Burada ince bir nokta var: 7.0’ın programmatic API’si henüz stabil değil. Yanı typescript paketini import edip (söylemesi ayıp) AST üzerinde dolaşan araçlarınız (ESLint plugin’leri, ts-morph kullanan kod jeneratörleri, custom transformer’lar) şu an için 7.0 ile tam uyumlu sayılmaz. Bu API’nın oturması biraz zaman alacak gibi dürüyor — büyük ihtimalle 7.1 tarafında netleşir. Outcome-Driven Learning: OpenEnv ve Foundry ile Kurumsal RL yazımızda bu konuya da değinmiştik.
Tuhaf ama, Buna rağmen ekip güzel düşünmüş; 7.0 ve 6.0’ın aynı projede yan yana yaşayabilmesi sağlanmış. CI pipeline’ınızda tsc derlemesini 7.0 ile koşturup lint ve test suite’ınızı 6.0 ile devam ettirebilirsiniz (geçiş döneminde gayet makul bir yöntem).
Türkiye’deki Ekipler İçin Ne Anlama Geliyor?
Doğrusu, Türkiye’de TypeScript kullanımı son 3-4 yılda ciddi şekilde arttı, bunu inkâr etmek zor. En çok da fintech, e-ticaret ve insurtech tarafında neredeyse standart hâline geldi bile denebilir. Kurumsal müşterilerde en sık duyduğum iki dert işe belli: build sürelerinin uzaması ve CI maliyeti. Intelligent Terminal 0.1.1: Bash Desteği, /fix ve /model Yenilikleri yazımızda bu konuya da değinmiştik. Bu konuyla ilgili RDBMS’ten Cosmos DB’ye Geçiş: AI Asistanı Ne Kadar İşe Yarar? yazımıza da göz atmanızı tavsiye ederim.
Şöyle düşünün: Azure DevOps’ta Microsoft-hosted agent kullanıyorsunuz ve standart bir Linux ajan dakika bazında para yiyor (çok romantik değil ama gerçek) (kendi tecrübem). Eğer build süreniz 8 dakikadan 1 dakikaya düşerse, ayda 3000 build çalışan bir ekipte bu baya somut TL tasarrufu demek oluyor. Sız hiç denediniz mi? FinOps gözlüğüyle bakınca, sadece bu hız artışı bile RC’yi pilot olarak denemeye değer kılıyor açıkçası.
Hmm, bunu nasıl anlatsamdı…
Bunu yaşayan biri olarak söyleyeyim, Bir de işin insan tarafı var ki bazen asıl fark orada çıkıyor. Editörde Find All References‘a bastığınızda 5 saniye beklemekle 200ms beklemek aynı his değil; biri akışı kırıyor, diğeri sessizce geçip gidiyor (küçük görünür ama gün sonunda etkisi büyüyor). Buna ölçmesi zor ama herkesin hissettiği verimlilik artışı diyebiliriz. Copilot Code Review’a AGENTS.md Desteği: Ne İşe Yarayacak? yazımızda bu konuya da değinmiştik.
Kurumsal vs Startup: Kim Ne Yapmalı?
Burada net konuşmak lazım; “RC’yi hemen production’a alın” demek pek akıllıca olmaz (ki bu çoğu kişinin gözünden kaçıyor)
- Küçük ekip / startup: Hemen deneyin derim. Yan etki riskiniz düşük, kazanç potansiyeli yüksek; local dev ve CI tarafında denemek için tam zamanı gibi dürüyor.
- Orta ölçek (10-50 geliştirici): Önce editör uzantısıyla bir hafta veri toplayın. CI’da paralel bir pipeline açın, aynı build’i 7.0 ile de çalıştırın; sonuçlar eşitse production CI’ya geçmek mantıklı olur. (bence en önemlisi)
- Enterprise (büyük monorepo, custom build araçları): Burada acele etmeyin bence. Hele bir de Webpack/Vite/Turbopack’in TypeScript entegrasyonu,
ts-loader,fork-ts-checker, ESLint kuralları gibi parçalar programmatic API’ye yaslanıyor; bunlar tam oturmadan koşmak gereksiz risk yaratır. Yine de pilot takımda deneme yapmak kötü fikir değil.
Performans Karşılaştırması: Beklentiler ve Gerçek
Microsoft’un kendi benchmark’larına ek olarak Bloomberg, Figma, Notion, Slack ve Vercel gibi şirketlerin pre-release sürümlerle çalıştığı da söyleniyor. Duyulan genel tablo şu: bazı senaryolarda build sürelerinin yarıdan fazlasının uçtuğu görülüyor.
Bunu biraz somutlaştıralım diye tipik örnekleri aşağıdaki tabloda topladım; bunlar Microsoft duyuruları ve topluluk benchmark’larından derlenen yaklaşık değerlerdir, sizin projede farklı çıkabilir:
| Senaryo | TS 6.0 | TS 7.0 RC | Hızlanma |
|---|---|---|---|
| VS Code projesinin tam derlemesi | ~78 s | ~7.5 s | ~10x |
| Playwright derlemesi | ~11 s | T~1? nope not needed?
Sıkça Sorulan SorularTypeScript 7.0 mevcut projelerimle uyumlu mu?Kendi deneyimimden konuşuyorum, Evet, uyumlu. Hani tip kontrol mantığı 6.0 ile aynı — yanı aynı hatalar, aynı çıktılar geliyor. Production CI’da hemen kullanmalı mıyım?Hani, Pilot olarak deneyin, bence gayet mantıklı. Ama kritik production pipeline’ı için biraz daha beklemenizi öneririm. RC stabil, aslında sorun orada değil — ekosistem henüz tam hazır değil. Yan yana çalıştırma (6.0 + 7.0) yaklaşımıyla riski sıfıra indirebilirsiniz. Node.js veya Bun gibi runtime’larla nasıl etkileşiyor?Şunu bilmek lazım: TypeScript 7.0 sadece derleyici. ESLint ve TypeScript ESLint çalışmaya devam edecek mi?Mevcut sürümler 6.0 ile çalışmaya devam ediyor, merak etmeyin. 7.0 üzerinde lint çalıştırmak içinse Ne zaman stabil sürüm gelecek?Microsoft kesin tarih vermedi. Ama tecrübeme göre RC sonrası genelde birkaç haftalık bir süreç oluyor. Programmatic API stabilizasyonu işe 7.1 ile hedefleniyor, yanı büyük ihtimalle birkaç ay sonra (ciddiyim) Kaynaklar ve İleri OkumaDürüst olmak gerekirse, Announcing TypeScript 7.0 RC — Microsoft DevBlogs |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder