5 पॉइंट द्वारा GN⁺ 2025-11-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust में शुरुआत से बनाया गया JavaScript इंजन, जिसकी संरचना ECMAScript स्पेसिफिकेशन को लगभग पूरी तरह सपोर्ट करने के लिए तैयार की गई है
  • फिलहाल ECMAScript भाषा के 97% से अधिक टेस्ट पास करता है, और test262 आधारित टेस्टिंग से सत्यापित है
  • V8 के Ignition डिज़ाइन और SerenityOS के LibJS से प्रेरित, और अधिकांश घटकों को न्यूनतम dependencies के साथ सीधे इम्प्लीमेंट किया गया है
  • bytecode VM, compacting garbage collector, custom RegExp इंजन और parser सहित स्पेसिफिकेशन-अनुरूप built-in objects और functions प्रदान करता है
  • अभी production उपयोग के लिए अधूरा है, लेकिन ES2025 स्तर की क्षमताओं वाले Rust-आधारित JS इंजन विकास में यह एक महत्वपूर्ण प्रगति है

Brimstone अवलोकन

  • Brimstone एक Rust में पूरी तरह नया लिखा गया JavaScript इंजन है, जिसका लक्ष्य ECMAScript स्पेसिफिकेशन को faithfully इम्प्लीमेंट करना है
  • यह फिलहाल ECMAScript भाषा के 97% से अधिक को सपोर्ट करता है और test262 टेस्ट पास करता है
  • यह अभी production environment में उपयोग के लिए तैयार नहीं, बल्कि विकासाधीन प्रोजेक्ट है

डिज़ाइन और इम्प्लीमेंटेशन

  • यह ECMAScript स्पेसिफिकेशन को सीधे इम्प्लीमेंट करता है, और V8 तथा SerenityOS के LibJS से डिज़ाइन प्रेरणा लेता है
  • इंजन के अधिकांश घटकों को बिना dependencies के सीधे इम्प्लीमेंट किया गया है, हालांकि ICU4X इसका एकमात्र अपवाद है
  • प्रमुख घटक:
    • V8 Ignition से प्रेरित bytecode-आधारित VM
    • काफ़ी unsafe Rust code में लिखा गया compacting garbage collector
    • custom RegExp इंजन और parser
    • स्पेसिफिकेशन-अनुरूप built-in objects और functions का इम्प्लीमेंटेशन

बिल्ड और रन

  • मानक Cargo commands के साथ बिल्ड और रन किया जा सकता है
    • cargo build से bs executable बनता है
    • cargo run से source से सीधे चलाया जा सकता है
  • JavaScript फ़ाइल चलाने का उदाहरण:
    cargo build
    ./target/debug/bs ./hello.js
    Hello world!
    

टेस्टिंग व्यवस्था

  • आधिकारिक test262 सहित first-party और third-party integration test suites का उपयोग किया जाता है
  • custom integration test runner शामिल है (cargo brimstone-test कमांड से चलाया जा सकता है)
  • unit और snapshot tests cargo test से चलाए जाते हैं
  • अतिरिक्त टेस्ट जानकारी tests/README.md में देखी जा सकती है

अभी तक इम्प्लीमेंट न की गई सुविधाएँ

  • ES2024 तक की सभी सुविधाएँ और फ़रवरी 2025 की TC39 बैठक के अनुसार Stage 4 proposals का अधिकांश हिस्सा इम्प्लीमेंट किया जा चुका है
  • अभी सपोर्ट न की गई सुविधाएँ:
    • SharedArrayBuffer
    • Atomics

2 टिप्पणियां

 
shakespeares 2025-11-19

कमाल है..

 
GN⁺ 2025-11-17
Hacker News राय
  • मैं लेखक हूँ। इस प्रोजेक्ट का यहाँ परिचय होना देखकर सच में बहुत खुशी हुई
    @ivankra ने इसे javascript-zoo में जोड़ा और benchmark चलाए, इसके लिए मैं आभारी हूँ
    पिछले 3 सालों से पूर्णता और performance बढ़ाने के लिए लगातार समय देता आया हूँ; यह एक hobby project था
  • अगर संक्षेप में तुलना करें, तो release build के आधार पर Boa लगभग 23MB है, जबकि Brimstone लगभग 6.3MB है
    Boa-स्तर की functionality पूरी करके इसे production के लिए मजबूत बनाया जाए तो आकार बढ़ सकता है, लेकिन इस छोटे आकार में स्पेक का 97% पास करना काफ़ी प्रभावशाली है
    • Boa अपने अंदर Unicode tables शामिल करता है
      Brimstone ऐसा नहीं करता, इसलिए आकार के अंतर का बड़ा हिस्सा वहीं से आता है
      Unicode को सही तरह से handle करने के लिए कई MB data चाहिए, इसलिए आजकल छोटे executable बनाना आसान नहीं है
      अगर Unicode support ज़रूरी है, तो न्यूनतम आकार की एक सीमा बन जाती है
    • जिज्ञासा है कि क्या size optimization अलग से लागू किए गए थे
      default settings आम तौर पर performance-केंद्रित होती हैं, इसलिए codegen-units=1 या panic removal जैसे options बदलने पर नतीजे अलग हो सकते हैं
    • आख़िरी कुछ प्रतिशत पूरा करने की प्रक्रिया में आकार अनुपातहीन रूप से बढ़ सकता है
      Boa लगभग 91% ही पास करता है, इसलिए Brimstone अधिक पूर्ण है
      छोटे प्रोजेक्ट्स में code अक्सर छोटा, साफ़ और maintain करना आसान होता है
      collaboration के साथ हमेशा एक निश्चित overhead आता है
  • जानना चाहता हूँ कि क्या Boa से तुलना की जा सकती है
    Boa repository
    • यहाँ benchmark results देखें, तो एक single-person project के लिए यह हैरान करने वाली हद तक परिपक्व लगता है
      functionality Boa से लगभग मिलती-जुलती है, और कुछ benchmarks में speed दोगुनी है
  • समझ नहीं आता कि Rust में लिखे गए प्रोजेक्ट्स हमेशा “Rust में लिखा गया” को इतना क्यों उभारते हैं
    • पहले “Lisp में लिखा गया”, “Ruby में लिखा गया”, “JavaScript में लिखा गया” जैसे दौर भी रहे हैं
      मुझे यह एक स्वाभाविक प्रवाह लगता है
    • Rust में (अगर unsafe न हो) कुछ bug classes मूल रूप से रोकी जा सकती हैं
      हालांकि कहा गया है कि यह प्रोजेक्ट unsafe का काफ़ी उपयोग करता है
    • Rust ecosystem में निवेश करने वालों के लिए यह नए प्रोजेक्ट खोजने का संकेत बनता है
    • Rust एक अच्छी भाषा है, लेकिन JS/TS से आने वाले युवा developers कभी-कभी इसे ज़रूरत से ज़्यादा पूजते हैं
      यह किसी तरह का Blub phenomenon लगता है
    • Rust में memory allocation और types को स्पष्ट रूप से संभालना पड़ता है, इसलिए development की कठिनाई अधिक है, लेकिन इसी वजह से उच्च गुणवत्ता वाला software भी ज़्यादा दिखता है
      आख़िरकार यह marketing element भी है, लेकिन औसतन इसकी पूर्णता अधिक होना सच है
  • “Compacting garbage collector, written in very unsafe Rust” यह पंक्ति बहुत मज़ेदार लगी
    • विषय से अलग है, लेकिन पुराने cracktro intros की याद आ गई
      OS boot होने से पहले Ikari intro चलने की कल्पना की
  • मौजूदा JS engines से तुलना करें तो यह कैसा है, यह जानने की उत्सुकता है
    • javascript-zoo के benchmarks देखें, तो मोटा-मोटी तुलना की जा सकती है
    • इस engine को Rust programs में सीधे embed किया जा सकता है
      C/C++ linking के बिना पूरी तरह Rust native
      40MB के single-binary server में JS scripting जोड़ी जा सकती है
      कई Rust-आधारित JS engines का आना वाकई शानदार बात है
  • Rust का सबसे बड़ा फ़ायदा memory safety माना जाता है, तो फिर जानबूझकर unsafe GC क्यों इस्तेमाल किया गया, यह सवाल है
    • Rust में high-performance GC नहीं है, इसलिए unsafe के साथ नई memory management system लागू करना तर्कसंगत है
      अगर unsafe area को न्यूनतम रखा जाए, तो मुझे यह ठीक लगता है
    • वास्तव में Vec जैसी standard library भी अंदरूनी तौर पर unsafe का उपयोग करती है
      महत्वपूर्ण बात यह है कि unsafe को छोटे दायरे तक सीमित रखा जाए ताकि उसकी जाँच संभव हो
      GC implementation ऐसा ही एक अपवाद क्षेत्र है
    • Rust का unsafe भी C++ की तरह इतना व्यापक undefined behavior नहीं लाता
      अगर मैं JS runtime Rust में बनाता, तो पहले उसे सुरक्षित तरीके से implement करता और ज़रूरत पड़ने पर ही unsafe इस्तेमाल करता
    • unsafe वह tool है जो compiler द्वारा न समझे जाने वाले हिस्सों पर developer को सीधा नियंत्रण देता है
      high-performance GC implement करने के लिए कुछ हिस्सों में यह अनिवार्य हो जाता है
    • व्यक्तिगत रूप से मुझे लगता है कि Rust की memory safety पर ज़ोर कुछ बढ़ा-चढ़ाकर पेश किया जाता है
      Rust बस एक तेज़ और अच्छी imperative language है
  • license दिखाई नहीं दे रहा
    • यह गलती थी। अब इसे MIT license के तहत जारी कर दिया गया है
    • मूल रूप से मैं बड़ी कंपनियों द्वारा शोषणकारी उपयोग की अनुमति न देने वाली दिशा का स्वागत करता हूँ
  • कुछ टिप्पणियों में “Rust कोई garbage-collected language नहीं है” इस बात को गलत समझा गया था
    • Rust GC language नहीं है, Rc या Arc इस्तेमाल करने पर ही reference counting लागू होती है