Go के साथ विस्तारयोग्य WASM एप्लिकेशन लिखना संभव

• Go 1.24 में WebAssembly(Wasm) से जुड़ी क्षमताओं का विस्तार किया गया है
• go:wasmexport directive जोड़ा गया है, जिससे Wasm module के बाहर से Go functions को कॉल किया जा सकता है
• WASI के लिए “reactor” build mode भी सपोर्ट किया गया है, जिससे कोड को लंबे समय तक सक्रिय अवस्था में चलाना संभव होता है
• इसके जरिए Wasm environment में Go applications को अधिक लचीले ढंग से extend करने की संभावना खुलती है

WebAssembly and the WebAssembly System Interface

• WebAssembly एक binary format है, जिसे web browser में high-performance low-level code चलाने के लिए बनाया गया था
• अब इसका उपयोग browser के बाहर भी व्यापक रूप से हो रहा है, और WebAssembly System Interface(WASI) के जरिए system resources के साथ interaction संभव है
• Go ने version 1.11 में js/wasm port के माध्यम से Wasm compilation को सपोर्ट करना शुरू किया था, और version 1.21 में नए GOOS=wasip1 port के जरिए WASI Preview 1 system call API को target करने वाला नया port जोड़ा

go:wasmexport का उपयोग करके Go functions को Wasm export करना

• Go 1.24 में नया जोड़ा गया go:wasmexport directive, Go functions को Wasm module के बाहर से कॉल किए जाने योग्य export के रूप में expose करने देता है
• उदाहरण: //go:wasmexport add की तरह declare करने के बाद function लिखें, तो Wasm host उस function को कॉल कर सकता है
• यह cgo के export directive जैसा है, लेकिन अधिक सरल mechanism से लागू किया गया है

Building a WASI Reactor

• WASI “reactor” ऐसे WebAssembly module को कहा जाता है, जो लगातार सक्रिय रहकर events या requests पर प्रतिक्रिया दे सके
• Go 1.24 में -buildmode=c-shared option का उपयोग करके WASI reactor build को सपोर्ट किया गया है
• यह build flag linker को _start function (command module का entry point) बनाने के बजाय _initialize function बनाने का निर्देश देता है
  • reactor की initialization _initialize function के जरिए होती है, और main function के बजाय पहले इसी function को कॉल करना चाहिए
• Wazero जैसे runtime के साथ उपयोग करने पर, _initialize कॉल के बाद export किए गए functions को ज़रूरत के अनुसार बार-बार फिर से कॉल किया जा सकता है
• यह तरीका उन environments में उपयोगी है, जहाँ Wasm को application के plugin या extension mechanism के रूप में इस्तेमाल किया जाता है

होस्ट और क्लाइंट के बीच समृद्ध type support

• Go 1.24 में go:wasmimport से कॉल होने वाले functions के parameter/return types पर लगी पाबंदियाँ कम की गई हैं
• उदाहरण के लिए, bool, string, int32 pointers, struct pointers आदि पास किए जा सकते हैं
  • हालांकि 64-bit और 32-bit environments के अंतर जैसी वजहों से कुछ सीमाएँ अब भी मौजूद हैं
• इससे Go Wasm applications को अधिक प्राकृतिक और सुविधाजनक तरीके से लिखा जा सकता है, और अनावश्यक type conversions हट जाते हैं

सीमाएँ

• Wasm, parallel processing के बिना single-thread architecture है
• go:wasmexport functions नए goroutines बना सकते हैं, लेकिन background goroutines बनाने वाले functions, go:wasmexport function के return होने के बाद तब तक चलते नहीं रहते जब तक Go-आधारित Wasm module को फिर से कॉल न किया जाए
• कुछ type restrictions कम की गई हैं, लेकिन go:wasmimport और go:wasmexport functions के साथ इस्तेमाल किए जा सकने वाले types पर अब भी सीमाएँ हैं
  • pointers वाले composite types को पास करने पर अभी भी constraints मौजूद हैं

निष्कर्ष

• Go 1.24 में WASI reactor build और go:wasmexport feature का जुड़ना, Go के Wasm ecosystem को काफी विस्तार देने वाला सुधार है
• इससे developers अधिक विविध Go-आधारित Wasm applications बना सकेंगे, और Wasm ecosystem में Go के लिए नई संभावनाएँ खुलेंगी

[click]

जब तक Wasm/gc का व्यापक रूप से अपनाया नहीं जाता, तब तक मुझे लगता है कि wasm target डेवलपमेंट बिना gc वाली भाषा में करना बेहतर होगा।

[xguru]

Go 1.24 रिलीज़ में इसे संक्षेप में बताया गया है, लेकिन यह उससे कहीं ज़्यादा महत्वपूर्ण अपडेट है।

[GN⁺]

Hacker News राय

• Go से बने WASM binaries के बहुत बड़े होने की समस्या है। TinyGo इससे निपटता है, लेकिन इसकी compile speed धीमी है और library चुनते समय सावधानी रखनी पड़ती है। दोनों समस्याओं से निपटने के लिए बहुत धैर्य चाहिए

  • Cloudflare Workers पर Go WASM आज़माने के लिए binary size की वजह से subscription चाहिए
  • आखिरी कोशिश में hello-world चल गया था, लेकिन उससे ज़्यादा जटिल चीज़ें size limit पार कर गईं
  • यह अफसोसजनक स्थिति है

• यह हैरान करने वाला है। याद रखने वाली बात:

  • Go का WebAssembly काम Go team ने नहीं, बल्कि volunteers ने design और implement किया है। इसलिए इसका timeline volunteers की availability पर निर्भर करता है

• मुझे ठीक से याद नहीं कि Go 1.24 से पहले भी Go functions को JS में export करना संभव था या नहीं। मुझे याद है कि पहले JS से export किए गए Go functions को बिना समस्या call किया जा सकता था

  • अगर कोई समझाए कि नया WASI functionality पहले की तुलना में कैसे बेहतर है, तो मदद मिलेगी (FFI के ज़रिए ज़्यादा types support करने के अलावा)
  • दूसरा सवाल: pointers को integer में cast करके strings और complex types को WASM module की instance memory से निकाला जा सकता था। अगर Go में मेरे types की binary representation के stable होने की guarantee है, तो मैं जानना चाहता हूँ कि goos=wasip1 इस्तेमाल करने पर बने WASM module में pointer pass करने का यह तरीका अभी भी valid है या नहीं

• main package में uppercase से शुरू होने वाले सभी functions को export करना ज़्यादा "Go" जैसा होता। Exporting language में सामान्य रूप से जैसे काम करती है, उसी तरह होनी चाहिए; compiler directive का इस्तेमाल सिर्फ तब बेहतर है जब lowercase से शुरू होने वाले नाम को explicitly बताना हो

  • यह मौजूदा cgo export approach जैसा ही है। यह पहले के उदाहरणों का पालन करता है। usability अब भी language के बाहर है

• WASM component model के साथ काम करने पर कोई उल्लेख नहीं है

• मैं जानना चाहता हूँ कि Go और WASM में garbage collection कैसे काम करता है

• काश कोई low-level language होती जिसमें strong typing और बेहतरीन WASM support होता

• मैं जानना चाहता हूँ कि host program में चल रहे WASM module को debug कैसे किया जाए

• मुझे चिंता है कि और ज़्यादा WASM features की चाह इस युवा ecosystem को अपरिवर्तनीय नुकसान पहुँचा सकती है। Go ने WASM में जो ज़्यादातर features जोड़े हैं, वे component model proposal पहले से merge हो चुका होता तो native रूप से किए जा सकते थे

  • standards धीरे-धीरे आगे बढ़ रहे हैं, और adoption बढ़ने के साथ यह जोखिम है कि WASI जैसे non-standard features को हमेशा support करना पड़े