Go ile genişletilebilir WASM uygulamaları yazmak mümkün

• Go 1.24 ile WebAssembly (Wasm) ile ilgili yetenekler genişletildi
• go:wasmexport yönergesi eklendi; böylece Go fonksiyonları Wasm modülünün dışından çağrılabilir hale geldi
• WASI için “reactor” derleme modu da destekleniyor; bu sayede kod uzun süre etkin durumda çalıştırılabiliyor
• Bununla birlikte, Wasm ortamında Go uygulamalarını daha esnek biçimde genişletmenin yolu açılıyor

WebAssembly and the WebAssembly System Interface

• WebAssembly, web tarayıcılarında yüksek performanslı düşük seviyeli kod çalıştırmak için oluşturulmuş bir ikili formattır
• Günümüzde tarayıcı dışında da yaygın biçimde kullanılıyor ve WebAssembly System Interface (WASI) aracılığıyla sistem kaynaklarıyla etkileşime girebiliyor
• Go, 1.11 sürümünde js/wasm portu ile Wasm derlemeyi desteklemeye başladı; 1.21 sürümünde ise yeni GOOS=wasip1 portu üzerinden WASI preview 1 sistem çağrısı API’sini hedefleyen yeni bir port eklendi

go:wasmexport kullanarak Go fonksiyonlarını Wasm Export olarak sunma

• Go 1.24’te yeni eklenen go:wasmexport yönergesi sayesinde, Go fonksiyonları Wasm modülünün dışından çağrılabilmeleri için export olarak açığa çıkarılabiliyor
• Örneğin //go:wasmexport add şeklinde tanımlayıp ardından fonksiyonu yazarsanız, Wasm host’u bu fonksiyonu çağırabilir
• Bu, cgo’nun export yönergesine benzer, ancak daha basit bir mekanizmayla uygulanır

Building a WASI Reactor

• WASI “reactor”, sürekli çalışabilen ve olaylara ya da isteklere tepki verebilen bir WebAssembly modülünü ifade eder
• Go 1.24’te -buildmode=c-shared seçeneği kullanılarak WASI reactor derlemesi destekleniyor
• Bu derleme bayrağı, bağlayıcıya _start fonksiyonunu (komut modülünün giriş noktası) üretmemesini, onun yerine _initialize fonksiyonunu üretmesini söyler
  • reactor, _initialize fonksiyonu üzerinden başlatılır ve main fonksiyonu yerine önce bu fonksiyon çağrılmalıdır
• Wazero gibi bir runtime ile kullanıldığında, _initialize çağrısından sonra export edilen fonksiyonlar istenildiği kadar yeniden çağrılabilir
• Bu yaklaşım, Wasm’ın uygulama eklentisi ya da genişletme mekanizması olarak kullanıldığı ortamlarda faydalıdır

Host ile client arasında daha zengin tip desteği

• Go 1.24’te go:wasmimport ile çağrılan fonksiyonların parametre ve dönüş türlerine ilişkin kısıtlamalar gevşetildi
• Örneğin bool, string, int32 pointer’ı ve struct pointer’ı gibi türler aktarılabiliyor
  • Ancak 64 bit ve 32 bit ortam farkları gibi nedenlerle hâlâ bazı kısıtlar bulunuyor
• Bu, Go Wasm uygulamalarının daha doğal ve rahat biçimde yazılmasını sağlıyor ve gereksiz tür dönüşümlerini ortadan kaldırıyor

Sınırlamalar

• Wasm, paralel işleme olmayan tek iş parçacıklı bir mimaridir
• go:wasmexport fonksiyonları yeni goroutine’ler oluşturabilir; ancak arka planda goroutine başlatan fonksiyonlar, go:wasmexport fonksiyonu döndükten sonra Go tabanlı Wasm modülüne yeniden çağrı yapılana kadar çalışmayı sürdürmez
• Bazı tür kısıtlamaları gevşetilmiş olsa da go:wasmimport ve go:wasmexport fonksiyonlarıyla kullanılabilecek türler üzerinde hâlâ sınırlamalar vardır
  • Pointer içeren bileşik türlerin aktarımında hâlâ kısıtlamalar bulunuyor

Sonuç

• Go 1.24’ün WASI reactor derlemesi ve go:wasmexport özelliği, Go’nun Wasm ekosistemini önemli ölçüde genişleten iyileştirmelerdir
• Bu sayede geliştiriciler daha çeşitli Go tabanlı Wasm uygulamaları oluşturabilir ve Wasm ekosisteminde Go için yeni olanakların önü açılır

[click]

Wasm/gc yaygın biçimde benimsenmeden önce, gc olmayan dillerle wasm hedefi için geliştirme yapmanın daha iyi olacağını düşünüyorum.

[xguru]

Go 1.24 sürüm notlarında bu konuya kısaca değiniliyor, ama aslında çok daha önemli bir güncelleme.

[GN⁺]

Hacker News görüşleri

• Go ile üretilen WASM ikililerinin çok büyük olması gibi ciddi bir sorun var. TinyGo bunu aşıyor, ancak derleme hızı yavaş ve kütüphane seçiminde dikkatli olmak gerekiyor. İkisinin de üstesinden gelmek için çok sabır gerekiyor

  • Cloudflare Workers üzerinde Go WASM denemek istiyorsanız, ikili boyutu nedeniyle abonelik gerekiyor
  • Son denememde hello-world çalışıyordu ama daha karmaşık olanlar boyut sınırını aştı
  • Üzücü bir durum

• Bu şaşırtıcı. Akılda tutulması gerekenler:

  • Go'nun WebAssembly çalışmaları Go ekibi tarafından değil, gönüllüler tarafından tasarlanıp hayata geçirildi. Bu yüzden takvim gönüllülerin müsaitliğine göre değişiyor

• Go 1.24'ten önce de Go fonksiyonlarını JS'e aktarmak mümkün değil miydi tam hatırlamıyorum. Daha önce JS'ten dışa aktarılan Go fonksiyonlarını sorunsuz çağırabildiğimi hatırlıyorum

  • Yeni WASI işlevselliğinin öncekine kıyasla nasıl iyileştiğini açıklarsa faydalı olurdu (FFI üzerinden daha fazla türü desteklemenin ötesinde)
  • İkinci soru: İşaretçileri tamsayıya çevirip WASM modülünün instance belleğinden string ve karmaşık türleri çıkarabiliyorduk. Go'da türlerimin ikili gösteriminin kararlı olduğu garanti ediliyorsa, goos=wasip1 kullanılarak üretilen WASM modülüne işaretçi geçirme yönteminin hâlâ geçerli olup olmadığını merak ediyorum

• Ana pakette büyük harfle başlayan tüm fonksiyonları dışa aktarmak daha "Go" tarzı olurdu gibi geliyor. Dışa aktarma dilde zaten genel olarak böyle çalıştığı için, yalnızca küçük harfle başlayanları açıkça adlandırırken derleyici yönergesi kullanmak daha iyi olurdu

  • Bu, mevcut cgo dışa aktarma yöntemiyle aynı. Önceki örnekleri takip ediyor. Kullanılabilirlik hâlâ dilin dışında kalıyor

• WASM component model ile çalışma konusunda hiçbir değinme yok

• Go ve WASM'in garbage collection'ı nasıl çalışıyor merak ediyorum

• Güçlü tiplere ve mükemmel WASM desteğine sahip düşük seviyeli bir dil olsaydı keşke

• Host program içinde çalışan WASM modülünün nasıl debug edildiğini merak ediyorum

• Daha fazla WASM özelliğine duyulan açlığın bu genç ekosisteme geri döndürülemez zararlar vermesinden endişe ediyorum. Go'nun WASM'e eklediği özelliklerin çoğu, component model önerisi zaten birleştirilmiş olsaydı native olarak yapılabilirdi

  • Standartlar yavaş gelişiyor ve benimsenme arttıkça WASI gibi standart dışı özellikleri sonsuza kadar desteklemek zorunda kalma riski var