Vercel'in Scriptc'si - İkili dosyaya JavaScript motoru gömmeden çalışan TypeScript yerel derleyicisi

 (github.com/vercel-labs)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • scriptc, normal TypeScript'i Node·V8·JavaScript motoru olmadan çalışan küçük yerel ikili dosyalara derler; gerçek TypeScript derleyicisinin tip denetimini ve Node davranışı uyumluluğunu korur
  • Kod yapısına göre statik derlenebilirliği belirleyip varsayılan olarak yerel koda dönüştürür; yalnızca --dynamic seçildiğinde npm paketlerinin JavaScript'i ve any tipindeki kod quickjs-ng ile çalıştırılır
  • Sınıflar·jenerikler·async/await·istisnalar·regex'ten Node sunucu API'lerine, fetch'e ve npm bağımlılıklarına kadar destekler; desteklenmeyen sözdizimini hata kodu·kod çerçevesi·düzeltme ipuçlarıyla birlikte reddeder
  • 800'den fazla programı Node ve yerel ikili dosyalarda çalıştırıp çıktı ve çıkış kodlarını karşılaştırır; bellek hatalarını AddressSanitizer ve referans sayımı denetimiyle kontrol eder
  • Apple M serisi ölçümlerinde başlangıç süresi yaklaşık 2.4ms, statik ikili dosyalar 170~200KB, tipik RSS 1~4MB'dir; dinamik mod ve gömülü bağımlılıklar dahil edildiğinde ikili dosya yaklaşık 3MB olur

Statik derleme modeli

  • Ayrı bir lehçe ya da anotasyon olmadan mevcut TypeScript'i kullanır ve tsconfig.json içindeki denetim katılığını ve TypeScript'in gerçek es2025 kütüphanesini uygular
    • Projede @types/node varsa onunla birlikte tip denetimi yapar
    • lowering olmayan erişilebilir kod için doğru tanılar üretir ve derlemeyi durdurur
  • scriptc coverage, analiz edilen ifade sayısını, statik derlenen oranı, engelleyici unsurları ve hata kodlarını gösterir
    • Örnekte 4.481 ifadenin 4.451'i, yani %99'u statik olarak derlenir
  • Çalıştırma biçimi açıkça üç aşamada ayrılır
    1. Statik derleme: Varsayılan moddur ve JavaScript motoru olmadan yerel koda dönüştürür
    2. Dinamik çalıştırma: --dynamic belirtildiğinde yaklaşık 620KB'lık quickjs-ng eklenir ve npm paketlerinin JavaScript'i ile any tipindeki kod çalıştırılır
      • Statik koddan gelen tüm değerler çalışma zamanında doğrulanır
      • Bildirilen tip ile değer uyuşmazsa belleği bozmadan yakalanabilen bir TypeError fırlatılır
    3. Reddetme: İşlenemeyen kod, hata kodu, kod çerçevesi ve çoğu durumda düzeltme ipuçlarıyla geri çevrilir; sessizce hatalı derleme yapmaz

Desteklenen TypeScript ve standart kütüphane

  • Dil özellikleri arasında tekli kalıtımlı sınıflar ve dinamik dispatch, closure'lar, jenerik monomorfizasyon, discriminated union'lar, destructuring, spread, template literal'lar, getter/setter ve iterator'lar bulunur
    • Güvenli olduğu kanıtlanırsa dinamik dispatch sanallaştırmadan çıkarılır
    • Discriminated union'lar, TypeScript'in narrowing kullandığı etiket değerleriyle işlenir
    • async/await, stackful fiber'lar ve JavaScript'e uyarlanmış zamanlamayla uygulanır
    • İstisnalar ve finally, opsiyonel·varsayılan·rest parametreler desteklenir
  • Regex için QuickJS'nin kullandığıyla aynı ECMAScript uyumlu bytecode yorumlayıcısı kullanılır ve yalnızca regex kullanan ikili dosyalara bağlanır
  • Standart kütüphane; UTF-16 semantiğini koruyan string'ler, JavaScript ile aynı sıra ve eşitlik kurallarına sahip array·Map·Set içerir
    • JSON tip dönüşümleri çalışma zamanında doğrulanır
    • Math, typed array, Buffer ve typed catch destekleyen Error hiyerarşisi de sağlanır

Node ve web API'leri

  • Node API'leri olarak fs, path, process, child_process, os, crypto, url/URL, zlib, zamanlayıcılar ve sinyal işleyicileri desteklenir
    • fs, senkron ve Promise API'leri sunar
    • child_process, pipe stream'lerini destekler
    • Event loop'un harici bağımlılığı yoktur
  • Sunucu yığını net, http, https, tls, dgram, dns, fs.watch, readline içerir ve gerçek proxy sunucuları derleyebilir
    • TLS için gömülü mbedTLS kullanılır
  • fetch ve stream'ler, Headers, AbortSignal gibi WHATWG web API'lerinin bir kısmı aynı yerel ağ·TLS yığını üzerinde uygulanır
    • Redirect, gzip, AbortSignal.timeout ve Node tarzı hata nedenleri desteklenir
    • libcurl ya da sistem HTTP bağımlılığı kullanılmaz

npm bağımlılıkları ve dinamik çalıştırma

  • --dynamic altında Node'un modül çözümleme biçimi kullanılır ve paketin sunduğu .d.ts temel alınarak tip denetimi yapılır
  • npm paketlerinin JavaScript'i build sırasında ikili dosyaya gömülür; bu nedenle çalışma sırasında node_modules okunmaz
  • scriptc coverage --dynamic, her ifadenin statik mi dinamik alanda mı çalıştığını ve kalan engelleri gösterir
  • JavaScript motoru yalnızca dinamik mod açıkça seçildiğinde eklendiği için ikili dosya boyutu sessizce artmaz

Doğruluk ve bellek güvenliği

  • Diferansiyel test, 800'den fazla programı Node ve yerel ikili dosyada ayrı ayrı çalıştırıp stdout, stderr ve çıkış kodlarını bayt düzeyinde karşılaştırır
    • Sayı çıktısı en kısa round-trip gösterimi izler ve 1 milyon double, Node ile karşılaştırılarak fuzz testiyle doğrulanır
    • Sunucular, her iki uygulamaya da gerçek istemci sürücüleri bağlanarak test edilir
  • Tüm test kümesi AddressSanitizer ve referans sayımı denetimi altında tekrar çalıştırılır; sızıntı veya use-after-free varsa build başarısız olur
  • Node'dan kasıtlı olarak farklı davranışlar birkaç düzinedir ve çoğunlukla zamanlama iç uygulamaları ile hata nesnesi özellikleriyle ilgilidir
    • Her fark belgelenir ve numaralandırılır; gizli farklara izin verilmez

Performans özellikleri

  • Apple M serisinde Node, Go, Rust, Zig ile aynı iş yükleri ve bayt düzeyinde aynı çıktı temel alınarak ölçülür
  • Başlangıç süresi yaklaşık 2.4ms'dir; Node'un yaklaşık 47ms'inden daha kısadır, Zig'e benzer ve Go·Rust'un önündedir
  • Statik ikili dosya boyutu 170~200KB'dir; --dynamic ve gömülü bağımlılıklar dahil edildiğinde yaklaşık 3MB olur
    • Karşılaştırma için verilen Go ikili dosyası yaklaşık 2MB, Node SEA ise 60~100MB'dir
  • Tipik bellek kullanımı RSS 1~4MB'dir; Node'da bu 67~116MB'dir
  • Çalışma zamanı, JavaScript'e uygun f64 semantiğini korurken çoğu iş yükünde sistem dilleriyle rekabet eder
    • Tamsayı çıkarımı ve sahiplik analizi yol haritasında yer alır

Açık kaçış yolları

  • comptime(() => ...), TypeScript'i derleme anında derleyicinin içindeki izole VM'de çalıştırır ve sonucu literal olarak ikili dosyaya yerleştirir
  • --ffi, yalnızca imzaya sahip TypeScript bildirimlerini doğrudan C ABI çağrılarına bağlar ve manifestte tanımlanan arşiv·nesne·sistem kütüphanelerini link eder
    • Sınırlar açıktır ve uzunluk bilgisi içerir
    • Ayrıntılı yöntem için Native FFI guide incelenebilir
  • JSON.parse(...) as Config gibi denetlenmiş tip atamaları, çalışma zamanı doğrulama kodu ekler
    • Doğrulama başarısız olursa expected number at $.port, got string gibi yanlış yolu ve beklenen·gerçek tipi içeren bir istisna fırlatır

Derleyici yapısı

  • İşleme hattı TypeScript → tsc ayrıştırma·tip denetimi → lowering → typed IR → C → clang → yerel çalıştırılabilir dosya sırasını izler
  • packages/compiler; tsc API tabanlı frontend, IR doğrulama·serileştirme, LLVM ve C backend'lerini içerir
    • Frontend ile backend arasındaki arayüz olarak yalnızca IR kullanılır
    • LLVM varsayılan kod üreticisidir; destek kapsamı dışındaki programlar için şeffaf bir yedek yol kullanılır
    • C, kalıcı referans backend olarak korunur ve --backend c ile kaynak satırı bilgisi içeren okunabilir çıktı üretir
  • packages/runtime; referans sayımı tabanlı değerler ve döngü toplayıcı, stackful fiber'lar, kqueue event loop'u, sunucu yığını ve JavaScript uyumlu sayı çıktısını uygular
    • Özellik bazlı linkleme kullanarak yalnızca gerçekten kullanılan özellikleri ikili dosyaya dahil eder
  • packages/cli, scriptc build, scriptc run, scriptc coverage komutlarını sunar

Kurulum ve geliştirme

  • npm install -g scriptc ile kurulur ve clang gerektirir
  • Ana platform macOS arm64'tür; Linux ve Windows ikili dosyaları cross-compile edilir
    • Her platform ayrı diferansiyel test yollarıyla doğrulanır
  • Geliştirmeye pnpm install && pnpm build ile başlanır
    • pnpm test, diferansiyel test kümesini ve tanı snapshot'larını çalıştırır
    • SCRIPTC_SAN=1 pnpm test, aynı testleri ASan ve referans sayımı denetimi altında çalıştırır
    • pnpm scriptc build x.ts --emit-ir, üretilen C'yi ve x.ir.json dosyasını korur
  • Tüm özellikler diferansiyel testlerle birlikte eklenir ve merge edilebilmesi için hem genel testler hem de bellek güvenliği testleri geçmelidir

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • Vercel, ayda bir gündem olacak bir proje çıkararak güvenilirliğini ve görünürlüğünü korumaya çalışıyor gibi. Ciddi bir şirketin ya da projenin scriptc kullanacağını sanmıyorum.
    Katkıda bulunanlara saygım var ama kod güçlü biçimde Claude ile üretilmiş izlenimi veriyor; Claude’un katkıda bulunan olarak gösterilmemesi de durumu daha şüpheli kılıyor.

    • Gerçekten muazzam ölçekte bir katkı ;-) commit
    • Aynı vibe coding lideri, Vercel’in Mayıs ayında büyük duyuruyla tanıttığı “ajanlar için programlama dili” zerolang projesini de yönetmişti. 1.200 commit’ten sonra geliştirme Haziran ortalarında durmuş.
      Proje / ilgili HN yazısı
    • Simon Willison’ın yalnızca README’yi düzenlemiş olduğu ve projeye fiilen anlamlı bir katkıda bulunmadığı görülüyor.
    • Katkı geçmişine bakınca yaklaşık %99’unun tek bir kişi tarafından vibe coding ile yapılmış olduğu izlenimi var; derleyici konusunda bir geçmişi de yok gibi.
    • Birçok SaaS ürünü Vercel ile iş birliği yapıyor ve geliştirme araçlarında Next.js ile React en üst seviye SDK’lar olarak görülüyor.

  • Porffor bir süredir aynı hedefin peşinde. Geliştiricisi CanadaHonk son derece yetenekli, ancak proje hâlâ Test262’nin yalnızca yaklaşık %68’ini geçiyor.
    Projenin kapsamını yanlış anlamıyorsam Vercel’in bu kadar hızlı ilerleme kaydetme biçimi oldukça şüpheli.

  • Tipik bir Vercel projesi. Yayınlanalı 5 gün olmuş, tamamı vibe coding, sebepsiz yere 1.500 yıldız almış; kimsenin sorununu çözmüyor ve en geç birkaç ay içinde bakımı bırakılacak gibi.

  • Sadece eleştirmek yerine yereldeki birkaç projeye doğrudan uygulamayı denedim, ama hepsinde kod kapsamı analizinde yüzlerce hata çıktı ve fiilen kullanılamazdı.
    Dış kütüphane olmadan sıfırdan yazarsanız ikili dosyaya derleyebilirsiniz; ama o durumda zaten en baştan düzgün derlenmeyi hedefleyecek şekilde tasarlanmış Rust, Go, Zig, D, C, V, Ada, C++, Nim, Swift, Kotlin Native, Haskell gibi dilleri kullanmamak için bir neden yok.

  • TypeScript’in avantajı yalnızca ifade gücü değil, devasa npm ekosistemiyle uyumluluğu. Paketlerin çoğu arayüzü yalnızca tip bildirimleriyle tanımlıyor, gerçek kodu ise JavaScript olarak dağıtıyor; bu yüzden paket kullanmak için pratikte bir JavaScript motoru gerekiyor.
    Sıfırdan başlayacaksanız ve hiçbir npm paketi kullanmayı planlamıyorsanız AssemblyScript kullanmak daha iyi. Node, TypeScript’in alt sürümler arasında bile geriye dönük uyumlu olmaması ve derleyici ayarlarının paketler arasında taşınabilir olmaması nedeniyle paketlerin TypeScript olarak dağıtılmamasını açıkça öneriyor.

    • scriptc, bu tür bağımlılıkları çalıştırması gerektiğinde isteğe bağlı olarak 620KB’lık quickjs-ng motorunu pakete ekleyerek bunu çözüyor gibi.
    • Bunu, çok bağımlılığı olan kodlardan ziyade daha büyük bir TypeScript projesiyle kod paylaşması gereken amacı net komut satırı araçları için kullanmak isterim.
    • Tipsiz kütüphane dağıtmak için bir gerekçe olabilir, ama bu gerekçenin tiplerin değerinden ağır bastığı sonucunu anlamak zor.

  • Böyle tek bir proje, HN gibi servislerin ön sayfasında sürekli görünmenizi sağlayabilir. Token yatırıp kimsenin istemediği ama inandırıcı görünen bir proje oluşturmak, açık kaynakla erişimi büyütmek ve bunu tekrarlamak bir büyüme stratejisi.
    12 ay sonra açık kaynak projelerin %90’ı gerçek kullanıcıları olmayan, yalnızca ilginç görünen vibe coding çıktıları olabilir. Artık tam bir derleyici bile kolayca üretilebiliyor; ama asıl mesele uzun vadeli bakım ve topluluk. Dikkat çekici bir başlık tek başına kullanıcıları elde tutmaz.
    Vercel ciddiyse gerçek maliyet ve risk üstlenip bunu kendi deneysel runtime’ı olarak benimsemeli.

  • Çok iyi bir problem alanı. Yapay zeka ile runtime kodunu optimize eden derleyici üretmeye benzer bir çalışmayı Zod’a uyguladım: zod-compiler
    Zod şemalarını derleme zamanında basit boolean işlem zincirlerine derleyerek kod değişikliği olmadan 2 ila 74 kat hızlandırıyor; eklenti de Zod çağrılarını derlenmiş parsing ile değiştiriyor. Optimizasyonların çoğunu Claude 100’den fazla yinelemeyle yazdı.
    Gerçek Zod ile sonuçları karşılaştırabildiğiniz için doğruluğu öznel olarak değerlendirmeye gerek olmaması bakımından scriptc ile aynı. Referans uygulaması ve benchmark’ı olan derleyiciler, serileştirme araçları, formatlayıcılar, sorgu planlayıcılar gibi her şeye uygulanabilir.

  • Claude ile scriptc ve Node benchmark’ını çalıştırdım. En avantajlı byte array sonucunda bile scriptc, özel optimizasyondan sonra Node 24’ten yaklaşık 7,5 kat yavaş.
    Buna karşılık yürütülebilir dosyanın başlangıcı 12 kat daha hızlı (1,5ms’ye karşı 18,6ms), belleği 72 kat daha az kullanıyor (2,5MiB’ye karşı 181MiB) ve runtime bağımlılığı olmayan tek bir 370KB yürütülebilir dosyaya dönüşüyor.

  • Küçük ve hızlı native yürütülebilir dosyalara ihtiyaç olduğunu kabul etmesi iyi, ama Java’nın onlarca yıldır yaşadığı sürece bakınca pratikliği konusunda şüpheliyim. 1990’lardaki GCJ teknik olarak fena değildi, fakat ekosistem desteği yoktu.
    Daha sonra GraalVM Native sorunu daha bütünlüklü ele aldı ve büyük kütüphaneler ile framework’ler uyumluluk sağlamaya yöneldi; ama bugün bile basit mevcut uygulamaları native olarak kusursuz çalıştırmak çok zor. scriptc gibi girişimler sevindirici, ancak pratik kullanıma ulaşması uzun ve zorlu görünüyor.

    • Bildiğim kadarıyla Graal ekibi de benzer bir meta yorumlayıcı yaklaşımı denedi. Native yürütmenin ele alamadığı dinamik bytecode yükleme veya reflection durumlarını Espresso Java uygulamasıyla yorumlamaya çalıştılar.
    • GCJ her zaman daha çok prototipe yakındı. Ciddi bir kullanıcı olsaydınız Excelsior JET, BEA JRockit gibi AOT araçları olan ticari JDK’leri satın alırdınız.
      Excelsior’ın ortadan kalkmasının nedenlerinden biri muhtemelen GraalVM ve OpenJ9’ın ücretsiz sunulması. PTC ve Aicas ise fazla ilgi görmeyen gömülü ve gerçek zamanlı müşteri kitlesi sayesinde hâlâ iyi şekilde faaliyet gösteriyor.

  • Geliştirme sürerse .NET AOT düzeyinde büyük bir başarı olma potansiyeli var. Yayınlanalı yalnızca birkaç gün olduğu için şu an hafifçe denenecek bir şey; ama terk edilmeyip gelişmeye devam ederse ekosisteme ciddi fayda sağlayabilir.
    Yapay zekayla üretilen kod da insanın yazdığı kod gibi geniş bir kalite aralığına sahip. Önemli yazılımlarda, kodu kendiniz yazarken uygulayacağınız standartlarla üretmeli ve tüm kodu incelemelisiniz; böyle kullanılırsa harika bir yöntem. İncelemesi yetersiz projelerde kalite ve geliştirici sorumluluğu düşük olabilir, bu da benimsemeyi zorlaştırır.
    Çevrimiçi tartışmalar “tamamı yapay zekayla üretildi” ve “asla yapay zeka kullanılmaz” uçlarına kayıyor; ama gerçek hayatta düşünceli muhakemeyi hızlandıran orta nokta makuldür. Aksi yazılımlar düşük kalite veya terk edilme riski nedeniyle kullanılmaktan kaçınılacak hâle gelir.