Açık konuşayım: TypeScript’in Go’ya taşınacağını ilk duyduğumda biraz kaşlarımı çattım. “Yine mi büyük bir yeniden yazım? Yine mi yıllar sürecek bir geçiş süreci?” diye düşündüm. Geçen hafta 7.0 Beta duyurusunu okuyunca fikrim baya değişti, hem de epey.
İnanın, Mesele şu: TypeScript ekibi, on yıldır TypeScript ile yazılmış (evet, kendi kendini derleyen) devasa kod tabanını Go’ya port etti. Sıfırdan yazmadılar, dikkat edin — port ettiler. Bu ikisi aynı şey değil. Sonuç da fena değil: ortalama 10 kat hız artışı. Bazı büyük kod tabanlarında daha da fazla (ki bu çoğu kişinin gözünden kaçıyor)
“Beta” etiketine takılmayın. Microsoft’un kendi iç ekipleri zaten milyonlarca satırlık kod tabanlarında kullanıyor. Bloomberg, Figma, Canva, Google, Notion, Slack gıbı ekipler de aylardır test ediyor. Yanı bu klasik bir “riskli beta” değil.
Neden Go? Neden şimdi?
Bu soruyu son bir yılda çok duydum. Özellikle.NET ve C# tarafındaki arkadaşlar, “Microsoft neden kendi dili yerine Go seçti?” diye soruyor. Dürüst olayım: seçim dilin kime ait olduğuyla ilgili değil, işin doğasıyla ilgili.
Bakın, TypeScript derleyicisi devasa miktarda AST (Abstract Syntax Tree) dolaşıyor, tıp kontrolü yapıyor, paralel iş yürütüyor; yanı yük biraz sert. Burada üç şey kritik oluyor: native kod hızı, düşük bellek tüketimi ve iyi bir paralellik modeli. Go’nün goroutine’leri ve paylaşımlı bellek modeli — en azından ben öyle düşünüyorum — tam buraya oturuyor..NET/C# de bunu yapabilirdi tabii — ama ekibin değerlendirmesi başka yöne kaymış. E peki, sonuç ne öldü? Jeremy Kahn ve ekibi blog yazılarında ayrıntılı anlatmışlar, meraklısı için link aşağıda duruyor.
Bir dakika — bununla bitmedi.
Hani, Bir de şu var: TypeScript zaten JavaScript’e derlenen bir “bootstrapped” projeydi. Yanı derleyici kendini derliyordu. V8 ne kadar hızlı olursa olsun, JIT warmup süresi, GC baskısı, tek thread modeli — bunların hepsi tavana çarpıyordu. Go’ya geçmek o tavanı biraz kaldırdı diyelim.
Port mu, yeniden yazım mı?
Bu ayrım önemli gerçekten. Ekip mevcut tıp kontrol mantığını yapısal olarak birebir koruyarak taşıdı; yanı el yordamıyla yeni davranış icat etmediler. TypeScript 6.0’da hangı köşe durumda hangı hatayı alıyorsanız, 7.0’da da aynı şeyi görmeniz gerekiyor. Semantik uyumluluk burada esas meseleydi zaten; milyon satırlık kod tabanını kırmadan derleyiciyi değiştirmek istiyorsanız başka yol pek yok.
İşte tam da bu noktada devreye giriyor. Azure Developer CLI ve Copilot: Terminalde AI Dönemi yazımızda bu konuya da değinmiştik. GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımızda bu konuya da değinmiştik.
Pratikte ne kadar fark ediyor?
Geçen hafta bir müşterimde — orta ölçekli bir e-ticaret firmasıydı, yaklaşık 400 bin satır TypeScript — tsgo’yu denedik. CI pipeline’ında tıp kontrolü adımı 2 dakika 14 saniyeden 13 saniyeye düştü. On üç saniye yanı. İlk anda “bir yerde hata var herhalde” dedik; cache yüzünden sanıldı önce ama değildi. Temiz build’de de tablo aynıydı. Azure DevOps MCP Server Nisan Güncellemesi: Neler Değişti? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Hyatt ve ChatGPT Enterprise: Otelde AI Dönemi Başladı yazımıza da göz atmanızı tavsiye ederim.
Logosoft’ta iç projelerimizden birinde — bankacılık müşterisi için geliştirdiğimiz ara katman — geliştiricilerin VS Code’da “Go to definition” tıklaması neredeyse anlık hâle geldi. Önceden 800ms-1.2s arası bekliyorduk; küçük gıbı duruyor ama gün içinde yüzlerce kez olunca can sıkıyor doğrusu. Bu konuyla ilgili Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımıza da göz atmanızı tavsiye ederim.
Bloomberg ve Figma gıbı firmalar da benzer rakamlar paylaştı. Build süreleri yarıdan fazla düşmüş, editör deneyimi (belki yanılıyorum ama) de “artık bekleme yok” noktasına gelmiş gıbı duruyor. Bu lafı Microsoft’un PR metninde okumak ayrı şey, sahada görmek ayrı şey.
Beklentiyi biraz yere indirelim:
- Küçük projelerde (50k satır altı): Belki 2-3 kat hız artışı görürsünüz; zaten hızlıysa çok dramatik hissettirmeyebilir.
- Orta projelerde (50k-300k): 6-8 kat civarı fark çıkabilir; CI tarafında hissedilir ölür.
- Büyük monorepo’larda (500k+): 10x ve üstü gayet mümkün; burada fark baya elle tutulur.
- Editör deneyimi: Projenin büyüklüğünden görece bağımsız kalıyor; çoğu yerde akıcılık belirgin artıyor.
Nasıl deneyeceksiniz?
Güzel taraf şu: mevcut TypeScript 6 kurulumunuzu bozmadan yan yana çalıştırabiliyorsunuz. Paket adı şimdilik farklı; ileride typescript adını alacak gıbı görünüyor (en azından benim deneyimim böyle)
# Kurulum
npm install -D @typescript/native-preview@beta
# Sürüm kontrolü
npx tsgo --version
# Çıktı: Version 7.0.0-beta
# Projeyi derle
npx tsgo --noEmit
# Watch mode
npx tsgo --watchtsgo, tsc‘nın yerine geçiyor diyebiliriz; aynı flag’ler var, aynı tsconfig.json, davranış da büyük ölçüde aynı kalıyor.
VS Code için ayrıca “TypeScript Native Preview” eklentisi var.
Kurun.
Ayarlarından aktif edin.
Bitti gitti.
Yanı sadece VS Code değil,
Neovim,
Helix,
Zed gıbı LSP destekleyen editörlerde de çalışıyor.
Hatta Copilot CLI gıbı araçlar bile bunu kullanabilir.
Türkiye’deki ekipler için pratik değerlendirme
İşin garibi, Lafı biraz Türkiye tarafına çekeyim.
Kurumsal müşterilerimde gördüğüm kadarıyla,
Türkiye’de TypeScript kullanımı son 3-4 yılda ciddi biçimde arttı;
özellikle fintech,
e-ticaret ve bankacılık tarafında neredeyse standart öldü.
Ama işin tatsız kısmı şu:
CI/CD pipeline’larında build süreleri bazen insanın moralini bozuyor.
Kısa bir not düşeyim buraya.
Neden?
Çünkü çoğumuz Azure DevOps ya da GitHub Actions’ta hosted runner kullanıyoruz.
Dakika başına ödeme yapıyoruz.
Bir müşterimde geçen ay hesap yaptık:
Azure Pipelines’ta aylık TypeScript derleme faturası yaklaşık 180 dolar civarındaydı.
Bunun büyük kısmı tıp kontrolü adımıydı.
TypeScript 7 ile bu rakam ayda yaklaşık 30 dolara düşecek gıbı duruyor.
Yıllık kabaca 1800 dolar tasarruf demek bu;
küçük ekip için hiç az değil.
Küçük bir detay: Bir de junior geliştirici tarafı var.
Bizde eğitimli yazılımcı açığı malum.
Ekibe yeni giren biri “IDE yavaş açılıyor”, “tıp kontrol bitmiyor”, “öneriler kafa karıştırıyor” dediğinde motivasyon hemen düşüyor.
7 sürümü bu açıdan da iyi bir nefes aldırıyor diyebilirim.
Hele bir de Ankara ve İstanbul’daki kurumsal ekiplere tavsiyem:
Önce staging CI pipeline’ınıza ekleyin,
paralel çalıştırın,
2 hafta metrik toplayın.
Sonra sonuçları yönetime gösterip production’a geçin.
Bu yöntemle geçişi anlatmak çok daha kolay oluyor.
Startup vs Enterprise: Kimin işine daha çok yarar?
Küçük bir ekipseniz (5-10 geliştirici), açıkçası hemen koşup geçmenize gerek yok; proje büyük değilse mevcut derleyici size zaten yetiyor olabilir.
Beta’yı merak edip deneyin. Kritik akışı şimdilik bozmayın derim.
Evet.
Sakın olmakta fayda var.
Açık konuşayım, Enterprise tarafındaysanız — ki çoğu okuyucum oraya yakın duruyor — durum değişiyor.
Monorepo’nuz varsa,
10+ geliştirici tsc bekliyorsa,
CI dakikaları canınızı yakıyorsa,
bu sürüm sizin için baya işe yarar.
Beta olmasına takılmayın;
zaten Microsoft içi ekipler production’da kullanıyor.
Benim önerim şu:
Bir sprint’e alın,
pilot proje seçin,
ölçün.
Sonra karar verin.
Küçük bir “ama”: Her şey tozpembe mi?
Değil.
Olmaz zaten.
Birkaç şeyi masaya koyayım:
- Plugin ekosistemi:
TypeScript’in API’si üzerine kurulu ESLint,
ts-node,
ts-jest gıbı araçlar henüz tam uyumlu değil.Bazıları çalışıyor,
bazılarının resmî desteği yok.Bu yıl sonuna kadar bu açığın kapanmasını bekliyorum. Şu anda fazla iyimser olmamak lazım.
- CUSTOM transformer’lar:
Özel AST dönüşümü yapan projeler
(mesela NestJS’in bazı decorator transformer’ları)
geçişte zorlanabilir.Ekip dokümantasyonda uyarıyor zaten.
- TYPED testing:
{tsd}
veya
{expect-type}
gıbı araçlarda durum biraz belirsiz kalabiliyor.Test ederken dikkat etmek gerekiyor.”
BİR MÜŞTERİDE tsgo ile ilk denemede tuhaf bir hata aldım —
ESLint’in TypeScript parser’ıyla çakışıyordu.
Çözüm basit sayılırdı:
ESLint’i eski tsc ile bırakıp,
derlemeyi tsgo ile yapmak.
Geçici bir workaround ama iş görüyor.
Üç ay sonra bu sorunun büyük ihtimalle tamamen çözülmüş olacağını düşünüyorum.
KARŞILAŞTIRMA TABLOSU
| Özellik | TypeScript {6}.0 (tsc) | TypeScript {7}.0 Beta (tsgo) |
|---|---|---|
| Runtime” | Node.js (JavaScript) | Native binary (Go) |
| Paralellik” | Sınırlı (worker threads) | Goroutine tabanlı, shared memory” |
| Tipik hız” | Referans” | ~10x daha hızlı” |
| Bellek tüketimi” | Yüksek (V8 heap) | Belirgin dü.üşük” |
| Tıp denetim semantiği” | Mevcut” | Birebir aynı” |
| API uyumluluğu’Aynıdır”> |
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.
