WASM 3.0 tamamlandı

• Wasm 3.0 standardı resmen duyuruldu ve 6-8 yıllık hazırlığın ürünü olan büyük ölçekli özellikler içeriyor
• 64 bit adres alanı, çöp toplama, typed reference'lar, tail call, istisna işleme gibi özelliklerle yüksek seviyeli dillerin Wasm'a daha kolay derlenmesini sağlıyor
• Temel yeni özellikler; yüksek performanslı uygulamalar, çeşitli dil çalışma zamanları, güvenlik ve genişletilebilirlik açısından fayda sağlıyor
• Web ortamının dışında, web dışı ekosistemlerde de daha büyük kapasite ve veri kümeleriyle çalışılması gereken kullanım senaryolarına uygun
• Halihazırda başlıca web tarayıcıları tarafından destekleniyor; Wasmtime gibi bağımsız motorlarda da yakında tamamlanacak ve Wasm böylece genel amaçlı bir yürütme platformu olarak daha da sağlamlaşacak

---

Wasm 3.0 sürümüne genel bakış

• WebAssembly standardının 3.0 sürümü 17 Eylül 2025'te yayımlandı
  • 2.0 sürümünün (2022'de tamamlandı) vektör komutları, bulk memory işlemleri, çoklu dönüş değerleri ve basit referans türlerini getirmesinden 3 yıl sonraki büyük güncelleme
  • W3C topluluk grubu ve çalışma grubu geliştirmeyi sürdürürken, bu sürüm 6-8 yıldır hazırlanan büyük özellikleri içeren oldukça kapsamlı bir değişiklik paketi sunuyor
  • Wasm, düşük seviyeli dil anlayışını korurken bellek ve tür sistemini güçlendirerek yüksek seviyeli dil derlemeyi daha iyi destekliyor
• 2.0 sürümünden sonra geliştirilen özellikler tamamlanarak Live standardı haline geldi ve web tarayıcılarıyla bağımsız motorlardaki destek genişliyor
  • Wasm özellik durumu sayfası üzerinden her motorun destek durumu takip edilebiliyor
  • Yeni SpecTec araç zinciri kullanılarak üretilen ilk sürüm olması sayesinde güvenilirlik arttı

Başlıca değişiklikler ve yeni özellikler

• 64 bit adres alanı
  • Bellek ve tablolar i64 türüyle tanımlanabiliyor
  • Wasm uygulamalarının adres alanı yaklaşık 4 GB'den fiziksel sınırlara kadar (teorik olarak 16 eksabayt) genişleyebiliyor
  • Web tarafında 16 GB sınırı uygulanıyor, ancak web dışı ekosistemlerde büyük uygulamaları ve veri kümelerini desteklemek için faydalı
• Çoklu bellek
  • Tek bir modül içinde birden fazla bellek nesnesi tanımlanıp bunlara doğrudan erişilebiliyor
  • Modül birleştirme, adres alanı ayrımı, arabelleğe alma ve güvenlik gibi çeşitli kullanım alanları sunuyor
  • wasm-merge gibi statik bağlama araçları artık tüm Wasm modüllerinde kullanılabilecek
• Çöp toplama (GC)
  • Doğrusal belleğin yanında, Wasm çalışma zamanının otomatik yönettiği depolama alanı desteği geliyor
  • Derleyiciler struct/array türleri ve unboxed tamsayılar gibi veri yerleşimlerini doğrudan tanımlayabiliyor
  • Yalnızca bellek yönetiminin temel yapı taşlarını sağlıyor; yüksek seviyeli nesne sistemleri veya closure'lar ise uygulama diline göre ayrı ayrı tasarlanabiliyor
• Typed reference'lar
  • Wasm tür sistemi genişletilerek heap değerlerinin biçimi ve fonksiyon referansları daha doğru şekilde ifade edilebiliyor
  • Alt türleme (subtyping) ve tür özyinelemesi destekleniyor; yeni call_ref komutuyla çalışma zamanında tür kontrolü olmadan güvenli dolaylı fonksiyon çağrısı yapılabiliyor
• Tail call
  • Mevcut fonksiyonun yığın alanını ek olarak kullanmadan, doğrudan dönüş yapan tail call yapısı destekleniyor
  • İşlevsel dillerde veya çalışma zamanı içi optimizasyonlarda kullanılabiliyor
• İstisna işleme
  • Wasm içinde yerel bir istisna işleme sistemi sunuluyor
  • İstisna etiketleri ve payload tanımı, seçmeli catch ve blok düzeyinde istisna işleyicileri sağlanıyor
  • Daha önce JS üzerinden dolaylı şekilde yapılan verimsiz yöntemlere gerek kalmadan taşınabilirlik ve performans iyileştirilebiliyor
• Relaxed vektör komutları
  • SIMD komutlarındaki donanım farklılıklarına uyum sağlamak için, bazı komutların ayrıntılı davranışını uygulama tarafına bırakan relaxed varyantlar sunuluyor
  • Yasal davranış kümesi içinde çeşitli optimizasyonlar yapılabiliyor
• Deterministik profil
  • Aynı komutun sonucunun belirlenimci olmadığı durumlarda (kayan nokta işlemleri, relaxed SIMD vb.) bile platformlar arası deterministik yürütme tanımlanıyor
  • Blokzincirler, yeniden üretilebilir sistemler gibi alanlarda yeniden üretilebilirlik ve taşınabilirlik sağlanabiliyor
• Özel anotasyon sözdizimi
  • Kaynak kod içinde insanlar tarafından okunup yazılabilen anotasyon sözdizimi ekleniyor
  • Standart bunları doğrudan yorumlamıyor, ancak gelecekte standartlar ve uzantı uygulamalarında kullanılabilecek

JavaScript bağlantısı ve uyumluluk

• JS string builtins
  • JS string değerleri externref olarak Wasm'a aktarılıp işlenebiliyor
  • Yeni yerleşik fonksiyonlar import edilerek, Wasm içinden doğrudan harici JS string'leri kullanılabiliyor

Wasm 3.0'ın faydaları ve görünümü

• Gelişmiş programlama dillerinin Wasm hedefli derlemesi için gerekli temeli sağlıyor
• Java, OCaml, Scala, Kotlin, Scheme, Dart gibi önemli diller de GC özelliğini aktif biçimde kullanmaya başladı

Spesifikasyonun hazırlanması ve dağıtım durumu

• Wasm 3.0, yeni SpecTec araç zinciriyle üretilen ilk standart oldu
• Başlıca web tarayıcılarının çoğu Wasm 3.0'ı zaten destekliyor; Wasmtime gibi bağımsız motorlarda da destek yakında tamamlanacak
• Wasm özellik durumu sayfasından motor bazında destek durumu görülebilir

[coremaker]

Bellek içi bir DB oluşturma girişimleri de ortaya çıkmaz mı?

[GN⁺]

Hacker News görüşleri

• 64 bitin spesifikasyonun varsayılanı haline gelmesi gerçekten en heyecan verici kısım; özellikle çevrimiçi video editörü gibi web uygulamaları 32 bit sınırı yüzünden şu anda bile birçok kısıtla karşılaşıyor. Figma da bu kısıtları doğrudan yaşıyor. Merak ettiğim bir nokta, mobil cihazlarda sekme başına adreslenebilir bellek sınırının aynı kalıp kalmayacağı; bu genelde OS tarafından tanımlanıyor, dolayısıyla 32 bit alanla doğrudan bağlantılı olmayabilir.

  • Video editor gibi uygulamaların belge tarayıcısının içine girmesinin doğru olup olmadığından emin değilim. İyi tasarlanmış yerel işletim sistemleri var ama artık kimse kullanmıyor olması üzücü. Eğer mevcut işletim sistemi süreçlerinin sunduğu sanallaştırmadan daha güçlü bir sanal makine gerekiyorsa, amaca uygun bir soyutlama tasarlamanın daha dürüstçe olduğunu düşünüyorum. Bir belge okuyucusunu zorla video editörüne dönüştürüyormuşuz gibi hissettiriyor.

  • Ne yazık ki Memory64 özelliğinin performans cezası epey büyük. Eski 32 bit modelde runtime her seferinde 4GB’nin tamamını ayırdığı için sınır kontrolü fiilen gerekmiyordu; ama 64 bitte sınırların doğrudan kontrol edilmesi gerekiyor. 4GB’tan fazla bellek gerçekten gerekiyorsa mecburen kullanılacak.

  • GC, referans türleri ve JS string API’sinin gelmesi de heyecan verici. Uzun zaman sonra sevindirici bir J; umarım iyidir.

  • Web uygulamalarının 4GiB bellek sınırına takılması artık normal görünüyor; sanki bugünlerde e-posta okumak için bile minimum 512GiB gerekiyormuş gibi bir dünyadayız.

• Garbage collection ekleniyor olması gerçekten etkileyici. Daha önce Wasm içinden stack’e doğrudan erişilemediği için stack scanning gibi geleneksel GC yaklaşımları mümkün değildi. Bunun yerine düşük seviye dil karakterini koruyup struct, array türleri, unboxed tagged int gibi yapılarla bellek yerleşimini açıkça tanımlıyorsunuz; ayırma ve yaşam süresi yönetimini ise Wasm üstleniyor. Hepsi bu. Gerçekten hayranlık uyandırıcı.

  • GC’nin gelmesiyle birlikte hem GC’siz hem de GC’li ortamları destekleyen bir yapının oluşması hoşuma gitti. Bu yönüyle D diline benziyor (D, hem GC’siz hem GC’li hızlı derleme ve çalıştırmayı destekliyor). Bu arada Dlang derleyicisi LDC ile artık Wasm da üretilebiliyor: Generating WebAssembly with LDC

  • Bu değişiklikle WebAssembly.Memory nesnesinin küçültülmesi mümkün olacak mı diye merak ediyorum. Belleği serbest bıraksanız bile tarayıcıya ayrılmış durumda kalması, çok kritik bir sorun: sorun1 sorun2

• WASM’in DOM’a doğrudan dokunabildiği günün ne zaman geleceğini merak ediyorum. Başta bunun WASM’in temel amaçlarından biri olduğunu sanıyordum ama şu an web’le neredeyse ilgisiz, ayrı bir canavar gibi hissettiriyor. JavaScript’i ne zaman kullanmak zorunda kalmayacağız diye de merak ediyorum.

  • Bunun ve multithread erişiminin düzgün şekilde desteklenmesini umuyorum. Rust ile bir uygulama yazıp wasm’a derleyip bunu aşağıdaki gibi doğrudan çağırmak isterdim:

    Yüksek performanslı web uygulamalarında veya tarayıcı eklentilerinde bellek ve performans sorunları gerçekten büyük, o yüzden bu çok faydalı olurdu. Uygulama wasm tabanlıysa v8’i atlayıp wasmer gibi bir motor da doğrudan kullanılabilir. Web teknolojilerinin Electron gibi masaüstü uygulamalarında kullanılmasının sebebinin masaüstü API’lerinin çok kötü ve taşınamaz olması olduğunu düşünüyorum. WASM’in yerel desteği güçlenirse Slack, VSCode, Discord gibi uygulamalar daha hafif hale gelebilir.

  • Bugün bile DOM’a WASM programlarından erişmek mümkün, sadece mevcut JS API’leri üzerinden gitmek gerekiyor. Bir dönem WASM’e özel API’ler tartışılmıştı ama dezavantajları fazla görüldüğü için sonunda rafa kaldırıldı.

  • İyi tasarlanmış bir frontend dili bekleyip izliyorum. Ama DOM’a erişirken JS sarmalayıcıdan geçmenin gerçekten o kadar verimsiz olup olmadığını merak ediyorum. Çoğu kod zaten yeterince verimsiz; dolayısıyla buradan gelen ek yükün pratikte çok belirgin olmadığını düşünüyorum.

  • JavaScript’in sorunlu olduğunu düşünüyorsanız DOM tarafının daha da kötü olduğunu göreceksiniz.

  • DOM referanslarına sahip olunduğunda garbage-collect edilebilen nesnelerin içine doğrudan bakabilmek işin zor kısmı. Web JavaScript güvenlik modelinde GC’nin içini gözlemleyebilmek mümkün olmamalı; ama WASM DOM’a işaretçi tutuyorsa bunun nasıl ele alınacağı sorun oluyor. GC düzgünce yerleştikten sonra bu konu yeniden tartışılabilir ama GC’siz WASM için neredeyse çözümsüz görünüyor.

• Yaklaşık bir yıldır WASM geliştirmelerini takip etmiyordum; sürüm bazlı release modeline geçildiğini şimdi fark ettim. Çeşitli özelliklerin hep opsiyonel kalacağını sanıyordum ama artık belirli bir sürüm uyumluluğu için tüm implementasyonların tüm özellikleri desteklemesi gerekiyor gibi görünüyor (WASM 3.0 vb.). WASM 3.0’ı tam destekleyen ikinci browser dışı runtime’ın hangisi olacağını merak ediyorum; ilki muhtemelen wasmtime olur (deno, v8 tabanlı olduğu için hariç). Özellikle GC zor bir özellik gibi geliyor. Ayrıca 3.0 release’inin eski "evergreen" modeliyle nasıl ilişkilendiğini bilen var mı? Evergreen modelinde resmi son sürümler yerine standart taslakları sürekli güncelleniyordu. Şu an en güncel Candidate Recommendation Draft fiilen standart sayılıyor: wasm özellik durumu wasm 2.0 haberi güncel standart taslağı

  • wasmtime, wasm 3.0’ın ana özelliklerinin tamamını zaten destekliyor. GC’yi meslektaşım Nick Fitzgerald birkaç yıl önce implement etti; tail call ise geçen yıl Jamey Sharp ve Trevor Elliott tarafından tam kapsamlı biçimde implement edildi (imza kısıtı olmadan, trampoline gerektirmeden). Exception handling de hazır ve yakında resmi release’e girecek. "3.0" release’ini, motorların bu özellikleri zaten hazırlamış olduğunun işareti olarak düşünebilirsiniz. Ben wasmtime ve Cranelift maintainer’ıyım.

  • Wizard araştırma amaçlı bir araç ama Wasm 3.0’ın tamamını destekliyor. Yalnızca interpreter ve baseline compiler içeriyor; v8 veya wasmtime gibi optimize edici bir compiler’ı yok. Bu yüzden hız olarak yavaş.

  • Sürümleme muhtemelen JavaScript’teki feature set yaklaşımına benzeyecek; yani her runtime hangi özellik kümesini desteklediğiyle anılacak. Wasm’de feature discovery’nin nasıl çalıştığını merak ediyorum.

• GC desteğinin eklenmesi gerçekten sevindirici. Eskiden WASM içinde stack’e doğrudan erişim olmadığı için geleneksel stack scanning tabanlı GC uygulaması neredeyse imkânsızdı.

• WebAssembly topluluğunun geliştirici deneyimine (DX) daha fazla önem vermesi gerektiğini düşünüyorum. Bir derleyiciyi bizzat yazıp hedef olarak Wasm kullandım ve deneyim epey rahatsız ediciydi. Biçimsel anlamı net olan bir dil sanıyordum ama pratikte Binaryen.js ile Wasm üretirken kendimi açık bir instruction set’i hedefliyormuş gibi hissetmedim. Bunun sebebinin muhtemelen Binaryen’in kendisi ve dokümantasyon eksikliği olduğunu düşünüyorum. Tek tesellim, Wasm metin parçacıkları yazmanın eğlenceli olmasıydı: jasmine wasm compiler

  • Binaryen, eski Wasm’ın AST olduğu dönemin bıraktığı çok fazla legacy taşıyor. Yeni özellikleri mevcut modele oturtmak zor oluyor. Bizim derleyicimiz soyut bir Wasm gösterimi için ayrı veri yapıları tanımlıyor; varsayılan derleme çıktısı .wasm, debug içinse .wat üretiyor. Bence oldukça sezgisel, instruction set tarafı fena değil: Scala.js wasm backend

  • TypeScript’ten Binaryen kullanırken ben de benzer şekilde tıkandım. Sonra Rust tabanlı wasm-tools’a geçtim; deneyim çok daha iyiydi.

  • Özellikle hangi kısımların zor geldiğini merak ediyorum. Validation error’lar gerçekten çok can sıkıcı olabiliyor; bu yüzden Wizard’a --trace-validation seçeneğini ekledim. Doğrulama sürecini daha anlaşılır şekilde görselleştiriyor.

  • binaryen.js dokümantasyonu ve binding’leri gerçekten oldukça yetersiz. Şu anda ana odak core Binaryen optimizasyonlarını iyileştirmek olduğu için JS/TS tarafı yavaş ilerliyor. Yine de biri JS/TS binding’lerini geliştirmeye zaman ayırırsa herkes için faydalı olur.

  • Sıfırdan saf assembly kodu üretmek daha kolaymış gibi de hissediyorum. Çoğu kaynak Rust araçlarına odaklanıyor ama elle yazma deneyimi de önemli. Compiler ve assembly aynı şey değil; Wasm’e sadece compiler geliştiricileri ilgi duyuyor gibi düşünmemek gerek.

• WASM için hâlâ umutluyum. Bu release harika görünüyor. envoy üzerinde yoğun trafik alan WASM eklentileri çalıştırıyoruz ve zellij gibi terminal uygulamalarının eklentilerinde de WASM kullanılıyor. Küçük bir yan projede de rust leptos tabanlı bir wasm web uygulaması işletiyorum. Dürüst olmak gerekirse bu üç kullanımın ikisi teknik olarak en iyi seçim olmayabilir ama bu yönelimin devam edeceğine inanıyorum. Emeği geçen herkesin eline sağlık.

• Basit olan en iyisi. Benim istediğim şey, Go struct aktarmanın daha kolay ve hızlı bir yolu. Go struct’larını runtime’a sokup çıkarırken kodun dolaşmaması ve ek yamalı çözümler gerektirmemesi güzel olurdu. Birden fazla dil için işe yarayan genel bir çözüm de iyi olur; ama bazı gerçekçi sınırlamalar içermesi benim için sorun değil. Benim için en önemlisi Go.

  • Buna katılıyorum; ayrıca GC’siz dillerde de pratikte çok daha iyi değil. Hatta gerçek hayatta wasm’de GC’li runtime’lar daha da dağınık olabiliyor. Şimdiye kadar yaşadığım en kötü JavaScript deneyimlerinden biri manuel pointer temizliğiydi. C++’ta scope dışına çıkınca destructor işi hallediyor; ama wasm ve JS’te her şeyi elle yönetmek gerekiyor, bu açıdan JNI günlerim daha iyiydi (Go dahil). Bir de tüm o uğraştan sonra bir struct’ı nihayet aktarınca çağrı başına ek yük yüksek oluyor ve sonunda daha büyük paketler halinde aktarmaya başlıyorsunuz. Ben de wasm’in en azından araç zinciri tarafının düzelmesini umuyorum; şimdiye kadar zorlayıcıydı.

  • Yerel kod tarafında çözüm aynı: diller arasında standart bir yapı (C struct vb.) üzerinde uzlaşmak ya da serialize/deserialize etmek. Birden çok runtime’ı karıştırarak kullanırken diller bunu doğrudan desteklemiyorsa gerçekten yorucu oluyor. Bunun neden sorun olduğu zaten açık.

  • Tam olarak ne istediğinizi bilmiyorum ama WASI’nin temelindeki component model yardımcı olabilir. Bu model, her modülün veriyi belleğe nasıl eşleyeceğini (ileride GC heap’e kadar) kendisinin belirlemesini sağlıyor; struct türleri gibi şeyler de arayüz olarak tanımlanabiliyor ve derleyiciler glue code’u otomatik üretebiliyor.

  • Bu bana WASM spesifikasyonundan çok kütüphane tarafının konusu gibi geliyor. Dahili olarak böyle code generator’ları iyi sonuçlarla kullandığım oldu.

• OpenMP desteğini bekliyorum. Deneysel olarak Solvespace’in web build’ini çalıştırıyorum; OpenMP desteği gelirse çok faydalı olur: online solvespace demo. Tarayıcıda çalışan açık kaynak bir CAD.

  • Solvespace’in gerçekten harika bir araç olduğunu düşünüyorum. Geçmişte YouTube eğitimlerini takip ederek bölünmüş klavye kasası tasarlayıp CNC ile üretmiştim. Hızlıca sonuç almak mümkün olmuştu. Bakımını sürdürdüğünüz için teşekkürler.

  • Şimdiye kadar gördüğüm WASM tabanlı web UI’lar arasında en iyisi bu olabilir. Masaüstü build’ini Emscripten ile çalıştırırken en zor kısım ne olmuştu, merak ediyorum.

• Henüz bahsedilmemiş bir nokta olarak ekleyeyim: multiple-memories özelliği WebGPU kaynak eşlemede gereksiz kopyaları önlemek için kullanılabilir mi diye merak ediyorum. Şu anda ArrayBuffer’a eşlenmiş bir yapı var ve WASM tarafında JS üzerinden kopyalamak gerekiyor; bu da performajı düşürüyor. Birden fazla WASM belleği ile Clang/LLVM’in address space özelliği çözüm olabilir gibi görünüyor ama pratikte gerçekten o kadar basit mi emin değilim.

  • multi-memory toolchain desteği tartışması var ama LLVM tarafında birden fazla adres alanını kullanan gerçek bir implementasyon yapıldı mı bilmiyorum.

  • Bütün bunlar bana eski segmented memory ve far pointer’ları hatırlatıyor. Son zamanlarda Gameboy oyunu yazıyorum, o yüzden bellek eşleme “eğlence”nin bir parçası sayılabilir; ama sınırsız bir ortamda bunu yeniden yaşamak istemem. DOS/Win16 dönemindeki far pointer’ların gömülüp kalmasının iyi bir nedeni vardı.