GCC-आधारित Rust संकलक की दिशा में प्रगति

मूल लेख ↗ Hacker News चर्चा ↗

GCC के लिए एक नियोजित Rust फ्रंटएंड इस बहस को फिर से हवा दे रहा है कि क्या भाषा के पास कई स्वतंत्र संकलक होने चाहिए या canonical `rustc` इम्प्लीमेंटेशन पर निर्भर रहना जारी रखना चाहिए। समर्थकों का कहना है कि GCC-आधारित Rust (gccrs) GCC के विश्लेषण प्लगइन्स, व्यापक CPU और embedded समर्थन, GPL-लाइसेंसयुक्त टूलिंग, और भविष्य के Rust language specification के लिए उपयोगी cross-checking लाएगा, जिसकी सुरक्षा-महत्वपूर्ण उद्योगों में बढ़ती मांग है। आलोचकों का जवाब है कि फ्रंटएंड की नकल करना सीमित प्रयासों की बर्बादी है, C++-जैसी fragmentation और असंगत “flavors” of Rust का जोखिम बढ़ाता है, और `rustc` with a GCC backend तथा Ferrocene-qualified toolchain जैसी मौजूदा पहलें parallel compiler ecosystem बनाए बिना अधिकांश व्यावहारिक ज़रूरतें पहले ही पूरी कर रही हैं।

gccrs बनाम विकल्पों के लिए प्रेरणा

  • बताए गए लक्ष्य: GCC के मौजूदा सुरक्षा/विश्लेषण प्लगइन्स का उपयोग करना, GNU-केवल टूलचेन वातावरणों में Rust for Linux का समर्थन करना, और एक GPL-लाइसेंस प्राप्त, LLVM-स्वतंत्र Rust संकलक प्रदान करना।
  • समर्थक GCC-केवल आर्किटेक्चर (जैसे, Dreamcast/SH‑4, विरासत CPU, कुछ RISC‑V कॉन्फ़िगरेशन, mips64) के लिए बेहतर कवरेज और जहाँ GCC पहले से स्थापित है वहाँ आसान उपयोग पर ज़ोर देते हैं।
  • आलोचकों का तर्क है कि rustc_codegen_gcc (rustc फ्रंटएंड द्वारा संचालित GCC बैकएंड) बहुत कम प्रयास में अधिकांश लाभ देता है और पहले से ही Linux kernel संकलित कर रहा है।

कई फ्रंटएंड और विखंडन

  • कई इम्प्लीमेंटेशन के पक्ष में: भाषा का “ऑडिट” करने, अस्पष्ट रूप से निर्दिष्ट व्यवहार को उजागर करने, एकल-इम्प्लीमेंटेशन जोखिम कम करने, और संकलक बग्स से टकराने पर उपयोगकर्ताओं को विकल्प देने में मदद मिलती है।
  • फ्रंटएंड्स के खिलाफ: C/C++ को चेतावनी के उदाहरण के रूप में उद्धृत किया जाता है—अलग-अलग विक्रेता, फ़्लैग्स, बग्स, और फीचर अंतर पोर्टेबल कोड को कठिन बनाते हैं। कई Rust उपयोगकर्ता आज के “एक संकलक, हर जगह चलता है” गुण को महत्व देते हैं और “GNU Rust” या विक्रेता forks से डरते हैं।
  • कुछ लोग सुझाव देते हैं कि कई फ्रंटएंड्स ज़्यादातर प्रयासों की पुनरावृत्ति करते हैं और लाइब्रेरी मेंटेनरों के लिए सूक्ष्म असंगतियाँ पैदा करते हैं।

भाषा विनिर्देश और मानकीकरण

  • कई लोगों का तर्क है कि Rust को एक औपचारिक spec/standard की आवश्यकता है; रिपोर्टों के अनुसार कुछ उद्योगों और नियामकों को सुरक्षा-महत्वपूर्ण उपयोग के लिए इसकी आवश्यकता होती है।
  • अन्य कहते हैं कि Rust के पास पहले से ही RFCs, एक Reference, और एक सक्रिय spec प्रोजेक्ट है; C++-शैली की ISO प्रक्रिया को धीमा और अनावश्यक माना जाता है।
  • वर्तमान व्यवहार के वर्णनात्मक spec और ISO मानक के लिए निर्देशात्मक मानक के बीच अंतर किया जाता है; कुछ लोग दूसरे के बिना पहले को चाहते हैं।

सुरक्षा-महत्वपूर्ण Rust और Ferrocene

  • Ferrocene (एक योग्य Rust टूलचेन) को इस बात के प्रमाण के रूप में उद्धृत किया जाता है कि Rust, बिना औपचारिक भाषा मानक के भी, किसी विशिष्ट संकलक संस्करण के विस्तृत spec के माध्यम से ISO 26262/IEC 61508 जैसे मानकों को पूरा कर सकता है।
  • प्रतिवाद: आधिकारिक भाषा मानक की अनुपस्थिति अभी भी कुछ डोमेनों के लिए Rust को अयोग्य ठहराती है और कुछ संगठनों द्वारा इसे “गंभीर नहीं” माना जाता है।

टूलचेन, आर्किटेक्चर, और बूटस्ट्रैपिंग

  • gccrs का स्वागत वे लोग करते हैं जो GCC-समर्थित लेकिन LLVM-समर्थित नहीं या उपेक्षित CPU पर Rust चाहते हैं, और वे लोग जो “pure GNU” या GPL टूलचेन पसंद करते हैं।
  • अन्य लोग नोट करते हैं कि GCC स्वयं में जटिल बूटस्ट्रैपिंग है और बाइनरी टूलचेन तथा क्रॉस-कंपाइलेशन पहले से ही अधिकांश व्यावहारिक बूटस्ट्रैपिंग समस्याएँ हल कर देते हैं।

शासन, एकाधिकार, और विकास की गति

  • कुछ लोग एकल इम्प्लीमेंटेशन “एकाधिकार” पर अविश्वास करते हैं और प्रतिस्पर्धा चाहते हैं; अन्य तर्क देते हैं कि समुदाय द्वारा संचालित कैनोनिकल संकलक किसी कॉर्पोरेट एकाधिकार जैसा नहीं है और ब्राउज़र-शैली के विखंडन से बचाता है।
  • Rust की आलोचना कभी फीचर्स पर बहुत तेज़ी से आगे बढ़ने (जटिलता) के लिए और कभी कुछ लंबे समय से मांगे गए फीचर्स पर बहुत धीरे बढ़ने के लिए की जाती है; कई फ्रंटएंड्स और एक औपचारिक मानक कुछ लोगों के लिए इस गति को और धीमा करने वाले, तो दूसरों के लिए आवश्यक परिपक्वता के संकेत हैं।