WASM 3.0 पूरा हुआ

 (webassembly.org)
17 पॉइंट द्वारा GN⁺ 2025-09-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Wasm 3.0 standard की आधिकारिक घोषणा हो गई है, और इसमें 6–8 साल की तैयारी के बाद आए बड़े फीचर्स शामिल हैं
  • 64-bit address space, garbage collection, typed references, tail calls, exception handling जैसी क्षमताएँ high-level languages को Wasm में और आसानी से compile करना संभव बनाती हैं
  • ये मुख्य नए फीचर्स high-performance applications, विभिन्न language runtimes, safety और scalability में मदद करते हैं
  • यह web environment के बाहर भी non-web ecosystem में बड़े आकार और बड़े data sets संभालने वाले उपयोग मामलों के लिए उपयुक्त है
  • प्रमुख web browsers में इसका समर्थन पहले से मौजूद है, और Wasmtime जैसे standalone engines में भी जल्द पूरा हो जाएगा, जिससे Wasm एक general-purpose execution platform के रूप में और मजबूत होगा

Wasm 3.0 रिलीज़ का अवलोकन

  • WebAssembly standard का version 3.0 17 सितंबर 2025 को जारी किया गया
    • version 2.0 (2022 में पूरा) के बाद यह 3 साल में आया बड़ा अपडेट है; 2.0 ने vector instructions, bulk memory operations, multiple return values, और simple reference types पेश किए थे
    • W3C Community Group और Working Group ने विकास जारी रखा, और इस रिलीज़ में 6–8 साल से तैयार किए जा रहे बड़े फीचर्स शामिल हैं, इसलिए यह काफ़ी बड़े पैमाने का बदलाव है
    • Wasm low-level language की अपनी मूल भावना बनाए रखते हुए memory और type system को मजबूत करता है, ताकि high-level language compilation को बेहतर समर्थन मिल सके
  • version 2.0 के बाद विकसित फीचर्स अब पूरा होकर Live standard का हिस्सा बन गए हैं, और web browsers तथा standalone engines में समर्थन बढ़ रहा है
    • Wasm फीचर स्थिति पेज में हर engine की support status को track किया जा सकता है
    • नए SpecTec toolchain का उपयोग करके इसका पहला version तैयार किया गया है, जिससे reliability बेहतर हुई है

मुख्य बदलाव और नए फीचर्स

  • 64-bit address space
    • memory और tables को i64 type के रूप में घोषित किया जा सकता है
    • Wasm applications का address space लगभग 4GB से बढ़कर physical limit तक (सैद्धांतिक रूप से 16 exabytes) जा सकता है
    • web में 16GB की सीमा लागू रहती है, लेकिन non-web ecosystem में बड़े applications और datasets के समर्थन के लिए यह उपयोगी है
  • multiple memories
    • एक ही module के भीतर कई memory objects घोषित और सीधे access किए जा सकते हैं
    • module merging, address space separation, buffering, security आदि में इसका उपयोग किया जा सकता है
    • wasm-merge जैसे static linking tools अब सभी Wasm modules पर इस्तेमाल किए जा सकते हैं
  • garbage collection (GC)
    • linear memory के अलावा, Wasm runtime द्वारा अपने-आप managed storage का समर्थन मिलता है
    • compiler सीधे struct/array types और unboxed integers जैसी data layouts घोषित कर सकता है
    • यह memory management के लिए केवल बुनियादी building blocks देता है; high-level object systems या closures का डिज़ाइन implementation language के अनुसार अलग-अलग किया जा सकता है
  • typed references
    • Wasm type system का विस्तार किया गया है, ताकि heap values के रूप और function references को अधिक सटीक रूप से व्यक्त किया जा सके
    • subtyping और recursive types का समर्थन है, और नए call_ref instruction से runtime type check के बिना सुरक्षित indirect function calls संभव हैं
  • tail calls
    • बिना अतिरिक्त stack space लिए, सीधे return करने वाली tail call संरचना का समर्थन
    • इसका उपयोग functional languages या runtime के अंदर optimization में किया जा सकता है
  • exception handling
    • Wasm के भीतर native exception handling system जोड़ा गया है
    • exception tags और payloads की declaration, optional catch, और block-level exception handlers उपलब्ध हैं
    • पहले JS के जरिए किए जाने वाले अप्रभावी workaround के बिना portability और performance बेहतर हो सकती है
  • relaxed vector instructions
    • SIMD instructions में hardware differences को ध्यान में रखते हुए, कुछ instructions के detailed behavior को implementation freedom देने वाला relaxed variant दिया गया है
    • वैध behavior set के भीतर कई तरह की optimizations संभव हैं
  • deterministic profile
    • समान instruction के लिए non-deterministic result वाली स्थितियों (floating-point operations, relaxed SIMD आदि) में भी platforms के बीच deterministic execution को परिभाषित करता है
    • blockchain, replayable systems आदि में reproducibility और portability सुनिश्चित की जा सकती है
  • custom annotation syntax
    • source code में इंसानों के लिए पढ़ने-लिखने योग्य annotation syntax जोड़ी गई है
    • standard इसे सीधे interpret नहीं करता, लेकिन भविष्य के standards और extensions में इसका उपयोग हो सकता है

JavaScript इंटरकनेक्शन और compatibility

  • JS string builtins
    • JS string values को externref के रूप में Wasm में पास और manipulate किया जा सकता है
    • नई built-in functions को import करके, Wasm के भीतर सीधे external JS strings का उपयोग किया जा सकता है

Wasm 3.0 की उपयोगिता और आगे की दिशा

  • उन्नत programming languages के Wasm target compilation के लिए आवश्यक आधार प्रदान करता है
  • Java, OCaml, Scala, Kotlin, Scheme, Dart जैसी प्रमुख languages भी GC फीचर का सक्रिय रूप से उपयोग करना शुरू कर रही हैं

स्पेसिफिकेशन निर्माण और वितरण की स्थिति

  • Wasm 3.0 नया SpecTec toolchain इस्तेमाल करके पहली बार तैयार किया गया standard है
  • ज़्यादातर मुख्य web browsers पहले ही Wasm 3.0 को support कर रहे हैं, और Wasmtime जैसे standalone engines भी जल्द पूरा समर्थन देने वाले हैं
  • Wasm feature status page पर हर engine की support status देखी जा सकती है

संबंधित पढ़ाई

2 टिप्पणियां

 
coremaker 2025-09-18

क्या इससे memory DB बनाने की कोशिशें भी शुरू नहीं हो सकतीं?
 
GN⁺ 2025-09-18
Hacker News राय

  • 64-bit का स्पेक का डिफ़ॉल्ट बनना वाकई रोमांचक है, खासकर online video editor जैसे webapp अभी भी 32-bit सीमाओं की वजह से कई तरह की पाबंदियाँ झेल रहे हैं, Figma ने भी इन सीमाओं को सीधे महसूस किया है, एक बात जानने की उत्सुकता है कि mobile devices पर per-tab addressable memory limit वैसी ही बनी रहेगी या नहीं, आमतौर पर यह OS द्वारा तय होती है, इसलिए हो सकता है कि इसका 32-bit space से सीधा संबंध न हो

    • मुझे शक है कि video editor जैसे apps का document browser के अंदर आना सही दिशा है या नहीं, जबकि हमारे पास अच्छे native operating systems हैं जिन्हें अब कोई इस्तेमाल नहीं करता, यह थोड़ा अफ़सोसजनक है, अगर मौजूदा OS processes से मिलने वाले virtualization से भी ज़्यादा शक्तिशाली virtual machine चाहिए, तो मेरा मानना है कि काम के हिसाब से नई abstraction डिज़ाइन करना ज़्यादा ईमानदार तरीका होगा, यह कुछ ऐसा लगता है जैसे एक साधारण document reader को ज़बरदस्ती video editor में बदल दिया गया हो

    • अफ़सोस की बात है कि Memory64 feature पर performance penalty काफ़ी बड़ी है, पहले 32-bit में runtime हर बार पूरे 4GB allocate कर देता था, इसलिए boundary check की लगभग ज़रूरत नहीं पड़ती थी, लेकिन 64-bit में boundaries सीधे जाँचनी पड़ती हैं, अगर 4GB से ज़्यादा memory सच में चाहिए तो फिर इसे इस्तेमाल करने के अलावा विकल्प नहीं है

    • GC, reference types, और JS string API का आना भी उत्साहजनक है, बहुत समय बाद प्यारा J फिर दिखा, उम्मीद है वह अच्छा होगा

    • webapp का 4GiB memory limit से टकराना तो अब लगभग स्वाभाविक लगता है, जैसे आजकल ईमेल पढ़ने के लिए 512GiB न्यूनतम चाहिए ऐसे ज़माने में जी रहे हों

  • garbage collection जुड़ना सच में हैरान करने वाला है, पहले Wasm में stack को सीधे access नहीं किया जा सकता था, इसलिए stack scanning जैसी पारंपरिक GC approach संभव नहीं थी, इसकी वजह से low-level language जैसा स्वभाव बनाए रखते हुए struct, array type, unboxed tagged int जैसी memory layout को साफ़-साफ़ बताया जा सकता है, और allocation व lifetime management Wasm संभालेगा, बस यहीं तक, कमाल है

    • GC आने के बाद भी non-GC environments तक को सपोर्ट करने वाली संरचना ताज़गीभरी लगती है, यह बात D language जैसी है (D non-GC और GC दोनों में तेज़ compile और execution सपोर्ट करता है), वैसे अब Dlang compiler LDC से भी Wasm बनाया जा सकता है Generating WebAssembly with LDC

    • सोच रहा हूँ कि क्या इस बदलाव से WebAssembly.Memory object का आकार छोटा करना संभव होगा, memory free करने के बाद भी उसका browser में allocated रहना बहुत महत्वपूर्ण मुद्दा है इश्यू1 इश्यू2

  • यह जानना दिलचस्प होगा कि WASM कब सीधे DOM को छू पाएगा, यही तो मुझे इसका मूल उद्देश्य लगता था, लेकिन अभी यह web से लगभग असंबंधित किसी अलग राक्षस जैसा महसूस होता है, यह भी जानना है कि JavaScript कब तक वैकल्पिक हो पाएगा

    • उम्मीद है कि यह हिस्सा और multithreaded access दोनों ठीक से सपोर्ट होंगे, मैं Rust app लिखकर उसे wasm में compile करूँ और फिर नीचे की तरह सीधे बुला सकूँ:

      high-performance webapp या browser extension जैसी जगहों पर memory और performance issues सच में बड़े होते हैं, इसलिए यह बहुत मददगार होगा, wasm-based app होने पर v8 को bypass करके wasmer जैसे engine भी सीधे इस्तेमाल किए जा सकते हैं, मेरा मानना है कि Electron जैसे desktop apps में web technologies इसलिए इस्तेमाल होती हैं क्योंकि desktop APIs बहुत खराब और non-portable हैं, अगर WASM का native support मज़बूत हो जाए तो Slack, VSCode, Discord जैसे apps हल्के हो सकते हैं

    • अभी भी WASM program से DOM access संभव है, बस existing JS API के जरिए जाना पड़ता है, एक समय WASM-only API पर चर्चा हुई थी, लेकिन कमियाँ ज़्यादा निकलीं और उसे छोड़ दिया गया

    • मैं अच्छी तरह डिज़ाइन की गई frontend language का इंतज़ार करते हुए देख रहा हूँ, लेकिन DOM access के समय JS wrapper से होकर जाना क्या सच में इतना inefficent है, इस पर शक है, ज़्यादातर code पहले से ही inefficent होता है, इसलिए यहाँ का overhead व्यवहार में इतना उभरकर नहीं आता होगा

    • अगर आपको JavaScript में समस्या लगती है, तो DOM की दुनिया उससे भी ज़्यादा गंभीर निकलेगी

    • DOM references रखने पर garbage-collectable objects को सीधे देखने की समस्या tricky है, web JavaScript security model में GC के अंदर झाँकना संभव नहीं होना चाहिए, लेकिन अगर WASM DOM के लिए pointer पकड़े हो तो उसे कैसे संभाला जाए यही सवाल है, GC ठीक से आने के बाद इस पर फिर चर्चा हो सकती है, लेकिन non-GC WASM में यह लगभग असंभव समस्या लगती है

  • मैंने लगभग एक साल से WASM development follow नहीं किया था, अब पता चला कि यह versioned release model पर चला गया है, मुझे लगा था कई features optional ही रहेंगे, लेकिन अब लगता है कि किसी implementation को किसी खास version compatible कहने के लिए उसे सभी features सपोर्ट करने होंगे (जैसे WASM 3.0), दूसरी बात, browser के बाहर दूसरा 3.0-complete runtime कौन होगा यह जानना रोचक है, शायद wasmtime पहला होगा (deno v8-based है इसलिए अलग), GC खास तौर पर tricky feature लगता है, कोई जानता है कि 3.0 release का पुराने "evergreen" model से क्या संबंध है, evergreen में लगातार standard drafts ही अपडेट होते हैं और अलग से official final versions नहीं रखे जाते, अभी का Candidate Recommendation Draft ही लगभग standard माना जाता है wasm feature स्थिति wasm 2.0 समाचार नवीनतम standard draft

    • wasmtime पहले से ही wasm 3.0 की सभी प्रमुख features सपोर्ट करता है, GC को मेरे सहयोगी Nick Fitzgerald ने कुछ साल पहले implement किया था, tail call को पिछले साल Jamey Sharp और Trevor Elliott ने full scope में implement किया था (signature restrictions के बिना, trampoline की ज़रूरत नहीं), exception handling भी आ चुकी है और जल्द औपचारिक release होगी, "3.0" release को इस संकेत की तरह देखा जा सकता है कि engines अलग-अलग features पहले से तैयार कर चुके हैं, मैं wasmtime और Cranelift का maintainer हूँ

    • Wizard research के लिए बना tool है, लेकिन वह Wasm 3.0 पूरी तरह सपोर्ट करता है, हालाँकि उसमें सिर्फ interpreter और baseline compiler हैं, v8 या wasmtime जैसे optimized compiler नहीं, इसलिए raw speed धीमी है

    • versioning शायद JavaScript की feature set शैली जैसी होगी, यानी हर runtime को उसके supported feature set से पहचाना जाएगा, मैं जानना चाहता हूँ कि wasm में feature discovery कैसे काम करेगी

  • GC support का जुड़ना सच में स्वागतयोग्य है, पहले WASM में stack तक सीधी पहुँच नहीं थी, इसलिए पारंपरिक stack scanning आधारित GC implementation लगभग असंभव थी

  • लगता है कि WebAssembly community को developer experience (DX) पर ज़्यादा ध्यान देना चाहिए, मैंने खुद एक compiler लिखकर Wasm को target किया था और अनुभव काफ़ी असुविधाजनक था, मुझे लगा था यह एक formal semantics वाली language है, लेकिन व्यवहार में Binaryen.js से Wasm generate करते समय किसी साफ़ instruction set को target करने जैसा एहसास नहीं हुआ, शायद इसकी वजह Binaryen खुद और documentation की कमी है, राहत की बात बस यह थी कि Wasm text snippets लिखना मज़ेदार था jasmine wasm compiler

    • Binaryen में पुरानी विरासत बहुत है क्योंकि शुरुआती Wasm AST-केंद्रित था, नई features को पुराने model में फिट करना मुश्किल होता है, हमारे compiler में हम abstract Wasm representation के लिए अलग data structure इस्तेमाल करते हैं, default compile output .wasm होता है और debugging के समय .wat निकालते हैं, मुझे यह काफ़ी intuitive लगता है इसलिए instruction set बुरा नहीं लगता Scala.js wasm backend

    • TypeScript में Binaryen आज़माते समय मुझे भी ऐसी ही घुटन महसूस हुई, फिर Rust-based wasm-tools पर गया और अनुभव बहुत बेहतर था

    • विशेष रूप से कौन-सा हिस्सा कठिन लगा, यह जानने की उत्सुकता है, validation error कई बार बेहद परेशान करने वाले होते हैं, इसलिए Wizard में --trace-validation option रखा गया है, यह validation process को समझने लायक तरीके से दिखाता है

    • binaryen.js की documentation और bindings सच में काफ़ी कमज़ोर हैं, इस समय ज़्यादा ऊर्जा core Binaryen की optimization improvements पर जा रही है, इसलिए JS/TS हिस्सा धीरे बढ़ रहा है, फिर भी अगर कोई JS/TS bindings सुधारने में समय लगाए तो सबके लिए अच्छा होगा

    • कभी-कभी लगता है कि शुरू से pure assembly code बनाना ज़्यादा आसान है, ज़्यादातर resources Rust tools पर केंद्रित हैं, लेकिन हाथ से लिखने का अनुभव भी महत्वपूर्ण है, compiler और assembly अलग चीज़ें हैं, Wasm में रुचि सिर्फ compiler developers को ही नहीं होती, यह नज़रिया भी ज़रूरी है

  • मुझे अभी भी WASM से उम्मीद है, यह release बढ़िया दिख रही है, envoy में high-traffic WASM plugins चला रहा हूँ, zellij जैसे terminal apps के plugins में भी WASM इस्तेमाल हो रहा है, छोटे side projects में rust leptos आधारित wasm webapp भी चला रहा हूँ, ईमानदारी से कहूँ तो इन तीन में से दो शायद तकनीकी रूप से सबसे सही विकल्प न हों, लेकिन यह दिशा आगे अच्छी लगती है, सबने बहुत मेहनत की है

  • simple सबसे अच्छा होता है, मेरी इच्छा बस इतनी है कि Go struct को pass करने का आसान और तेज़ तरीका मिले, runtime में go struct डालते या निकालते समय code उलझे नहीं और कोई जोड़ी-तोड़ समाधान न लगाना पड़े, कई languages में काम आने वाला सामान्य समाधान भी अच्छा होगा, और अगर उसके साथ कुछ व्यावहारिक सीमाएँ हों तो भी ठीक है, मेरे लिए go सबसे अहम है

    • इस बात से सहमत हूँ, और non-GC languages में भी स्थिति व्यवहार में बहुत बेहतर नहीं है, सच तो यह है कि wasm में GC वाले runtimes कई बार और भी ज़्यादा बिखरे हुए लगते हैं, मैंने अब तक JavaScript में सबसे बुरा अनुभव manual pointer cleanup के साथ किया, C++ में scope से बाहर जाते ही destructor काम कर देता है, लेकिन wasm और js में सब कुछ खुद संभालना पड़ता है, उस लिहाज़ से JNI के दिन बेहतर लगते थे (go समेत), और इतनी मेहनत के बाद जब किसी तरह एक struct pass हो भी जाए, तब per-call overhead इतना बड़ा होता है कि आखिर में चीज़ों को बड़े पैकेट में wrap करके भेजना पड़ता है, मैं भी चाहता हूँ कि wasm का pipeline कम से कम ठीक हो जाए, अभी तक यह कठिन रहा है

    • native code में तो समाधान वही रहता है: languages के बीच standard structures (जैसे C struct) अपनाओ या serialize/deserialize करो, जब कई runtimes मिलाकर इस्तेमाल करते हैं और languages direct support नहीं देतीं, तब हालत सच में थका देने वाली हो जाती है, यह समस्या क्यों है, यह स्पष्ट है

    • मैं ठीक-ठीक नहीं जानता कि आप क्या चाहते हैं, लेकिन WASI की नींव में जो component model है वह मदद कर सकता है, इस model में हर module खुद तय करता है कि data को memory में कैसे map करना है (आगे चलकर शायद GC heap तक भी), और struct types जैसी चीज़ों को interface के रूप में define किया जा सकता है ताकि compiler glue code अपने आप generate कर दे

    • यह मुझे WASM spec से ज़्यादा library layer की चीज़ लगती है, अंदरूनी तौर पर ऐसे code generators के साथ मेरा अच्छा अनुभव रहा है

  • OpenMP support का इंतज़ार है, मैं प्रयोग के तौर पर Solvespace का web build चला रहा हूँ, OpenMP support मिल जाए तो बहुत फ़ायदा होगा online solvespace demo, यह browser में चलने वाला open-source CAD है

    • Solvespace वाकई शानदार tool है, मैंने पहले YouTube tutorial देखकर इससे split keyboard case डिज़ाइन किया था और CNC से बनवाया भी था, तेज़ी से नतीजा मिला था, इसे maintain करने के लिए धन्यवाद

    • अब तक देखे गए WASM-based web UI में यह सबसे अच्छा लगता है, desktop build को Emscripten से चलाते समय सबसे कठिन हिस्सा क्या था, यह जानना चाहूँगा

  • एक बात जो अभी तक किसी ने नहीं कही: multiple-memories feature क्या WebGPU resource mapping में duplicate copy से बचने के काम आ सकता है, अभी चीज़ें ArrayBuffer में map होती हैं इसलिए WASM को JS के जरिए copy करना पड़ता है और performance का नुकसान होता है, कई WASM memories और Clang/LLVM की address space feature शायद समाधान हो सकती हैं, लेकिन यह वास्तव में इतना सरल है या नहीं, पता नहीं

    • multi-memory toolchain support पर चर्चा हुई थी, लेकिन LLVM में multiple address spaces का उपयोग करने वाला implementation सच में हुआ या नहीं, यह मुझे नहीं पता

    • यह सब मुझे पुराने segmented memory और far-pointers की याद दिलाता है, मैं हाल में Gameboy games लिख रहा हूँ इसलिए memory mapping वहाँ "मज़े" का हिस्सा है, लेकिन बिना ऐसी मजबूरी वाले माहौल में वही चीज़ दोहराना पसंद नहीं करूँगा, DOS/Win16 के दौर में far pointers को दफ़नाने की अच्छी वजह थी