Swift में WebAssembly समर्थन के लिए विज़न प्रस्ताव

• Swift कम्युनिटी लगातार WebAssembly(Wasm) समर्थन विकसित करती रही है, और इसी आधार पर एक दीर्घकालिक विज़न प्रस्तावित किया गया है
• WebAssembly पोर्टेबिलिटी, सुरक्षा और प्रदर्शन पर ज़ोर देने वाला एक वर्चुअल मशीन instruction set है, जिसे विभिन्न प्लेटफ़ॉर्म पर चलाया जा सकता है
• Swift में Wasm समर्थन मिलने से ब्राउज़र सहित नए environments में Swift का उपयोग संभव होगा, और client/server applications दोनों में इसके उपयोग की संभावनाएँ बढ़ेंगी

सुरक्षा और system interface विशेषताएँ

• Wasm सीधे system access के बिना केवल explicitly import किए गए functions ही चला सकता है, इसलिए यह सुरक्षा के लिहाज़ से लाभकारी है
• WASI(WebAssembly System Interface) Wasm को host OS के साथ interoperate करने के लिए standard API प्रदान करता है
• Swift wasm32-unknown-wasi target पर WASI libc के आधार पर काम करता है, और C interop के माध्यम से यह पहले से उपयोग योग्य है
• W3C Component Model के जरिए Wasm के type system और module interconnection का एकीकृत प्रबंधन कर रहा है
  • wit-tool के माध्यम से Swift declarations से .wit बनाया जा सकता है, और उल्टी दिशा भी समर्थित है

प्रमुख उपयोग परिदृश्य

• Swift macros को Wasm में compile करके कहीं भी चलने वाले binaries के रूप में वितरित किया जा सकता है
• SwiftPM plugins, manifests, macros आदि के execution को virtualize करके सुरक्षा बढ़ाई जा सकती है
• Wasm JIT या AOT compilation के जरिए optimized binaries बना सकता है, इसलिए performance loss को न्यूनतम रखा जा सकता है
• Wasm में virtualized Swift components अलग process के बिना चल सकते हैं, जिससे IPC overhead हट जाता है

प्रस्तावित लक्ष्य

1. Swift standard library में WASI support API का दायरा बढ़ाना
   • test automation के लिए CI environment बनाना आवश्यक है
2. cross-compilation tools में सुधार
   • Swift SDK के version management और installation को सरल बनाना
3. Component Model integration
   • नवीनतम WASI specification को Swift में भी उपयोग योग्य बनाने के लिए समर्थन
4. अन्य Wasm components के साथ interop बेहतर बनाना
   • लक्ष्य यह है कि Swift में Wasm components उपयोग करने का अनुभव C/C++ के बराबर हो
5. Wasm में Swift debugging environment में सुधार

debugging से जुड़ी बातें

• Wasm की debugging सीमित है, इसमें अपने आप introspection capability नहीं है
• दो प्रमुख approaches मौजूद हैं
  1. LLDB और GDB protocol को support करने वाला Wasm runtime
  2. Wasm engine में built-in debugger
• browser environment और non-browser environment के लिए अलग debugging approaches की आवश्यकता है
• Chrome DevTools जैसे tools में DWARF जानकारी का उपयोग संभव है, लेकिन Swift metadata और JIT expression evaluation के लिए अतिरिक्त integration की ज़रूरत है

multithreading और concurrency

• Wasm में फिलहाल केवल sequential consistency को support करने वाले atomic operations मौजूद हैं
• thread creation host environment पर निर्भर है
• threading के लिए दो प्रस्ताव मौजूद हैं:
  • wasi-threads (मौजूदा तरीका, कुछ tools और runtimes में समर्थित)
  • shared-everything-threads (नया प्रस्ताव, जो भविष्य में standard बन सकता है)
• Swift wasm32-unknown-wasi (single-thread), wasm32-unknown-wasip1-threads (multithread) को support करता है
• फिलहाल libdispatch, wasi-threads को support नहीं करता, इसलिए single-thread आधारित Swift Concurrency executor का उपयोग किया जा रहा है

64-bit address space

• Wasm डिफ़ॉल्ट रूप से 32-bit address space का उपयोग करता है
• 64-bit memory proposal(memory64) अभी implementation चरण में है
• Swift में इसे support करने के लिए WebAssembly toolchain के सहयोग या Swift metadata structure में बदलाव की आवश्यकता होगी

shared libraries

• इसके लिए दो तरीके मौजूद हैं
  1. Emscripten-style dynamic linking: non-standard है और runtime features पर निर्भर करता है
  2. Component Model आधारित static linking: runtime की विशेष सुविधाओं के बिना भी उपयोग संभव है, लेकिन runtime loading संभव नहीं
• Swift में shared libraries का उपयोग करने के लिए PIC(Position-Independent Code) mode में compile करना होगा और निर्धारित linking convention का पालन करना होगा

[kandk]

Swift अच्छा है, लेकिन क्या छोड़ा जा चुका Swift फिर से ज़िंदा हो सकता है..