Rust शैली मार्गदर्शिका
Google की नई Rust शैली मार्गदर्शिका इस बात पर बहस छेड़ रही है कि क्या सख्त, मानव-केंद्रित conventions अभी भी मायने रखते हैं, जब बड़े codebases increasingly AI की मदद से लिखे और reviewed किए जा रहे हैं। कई commenters का तर्क है कि consistent APIs, crate structure, और patterns (जैसे bools की जगह enums, छोटे crates, और ownership बनाम Rc/Arc की स्पष्टता) readability, safety, और बड़े-team coordination के लिए और भी महत्वपूर्ण हैं—खासकर monorepos और distributed systems में। यह thread आगे Rust की भूमिका को C और C++ के सापेक्ष, AI-assisted दुनिया में long-term maintainability, और आज Google की engineering guidelines को कितना महत्व देना चाहिए, इस व्यापक बहस तक ले जाता है.
LLM/“Agentic” युग में शैली मार्गदर्शिकाओं की भूमिका
- कुछ लोगों का तर्क है कि शैली मार्गदर्शिकाएँ अब कम प्रासंगिक हैं, क्योंकि कोड LLM द्वारा जनरेट होगा और उसे मनुष्य सीधे पढ़ने के बजाय मुख्यतः AI स्पष्टीकरणों के माध्यम से देखा जाएगा।
- अन्य लोग इसका ज़ोरदार प्रतिवाद करते हैं कि:
- पठनीयता, दीर्घकालिक रखरखाव, और क्रॉस-टीम काम के लिए शैली अभी भी महत्वपूर्ण है।
- सुसंगत API और implementation design, चाहे कोड कोई भी लिखे, उपयोगी रहते हैं।
- “agentic” दुनिया में, स्पष्ट नियम मनुष्यों को AI आउटपुट की सार्थक समीक्षा और नियंत्रण करने में मदद करते हैं।
- कुछ लोगों ने रिपोर्ट किया कि वे LLMs को style guides देते हैं; मॉडल हमेशा उनका पालन नहीं करते, और मज़बूत अधिकार या automated linters के बिना manual enforcement कठिन है।
Rust बनाम C/C++ और भविष्य
- इस पर बहस कि क्या नया C/C++ अभी भी लिखा जा रहा है:
- कई लोग कहते हैं: हाँ — defense, embedded, HPC, games, बड़े मौजूदा codebases, और प्रमुख projects अभी भी बड़े पैमाने पर C/C++ का उपयोग करते हैं।
- अन्य का दावा है कि Rust C/C++ को “खा” रहा है, विशेषकर security-sensitive और नए greenfield systems में, और कुछ कंपनियाँ Rust पर “all in” हैं।
- प्रतिवाद:
- ecosystems (जैसे game dev) को बदलने में कई वर्ष लगेंगे, अगर वे कभी बदलें भी।
- कुछ domain (अत्यधिक performance, data-oriented designs) Rust के borrow checker को C++ की तुलना में ergonomically महंगा मान सकते हैं।
- कुछ लोग मानते हैं कि LLMs भाषा-चयन को कम महत्वपूर्ण बना देंगे, या Rust को भी एक intermediate representation तक सीमित कर देंगे।
बहस के अधीन विशिष्ट शैली नियम
- Enums बनाम bools: व्यापक रूप से पसंद किए जाते हैं; enums व्याख्या को सीमित करते हैं और भ्रमित करने वाले flags को रोकते हैं।
- Rc/Arc बनाम lifetimes:
- एक पक्ष: stack से बाहर निकलने वाले data के लिए Rc/Arc को खुलकर उपयोग करें; lifetimes “अजीब” हैं।
- दूसरा पक्ष: shared ownership यह अस्पष्ट करती है कि किसके पास क्या है; lifetimes अधिक स्पष्ट हैं और Rc/Arc को वास्तविक साझा-उपयोग आवश्यकताओं के लिए आरक्षित किया जाना चाहिए।
- Getters/setters naming:
- मार्गदर्शिका getters के लिए bare method names और setters के लिए
set_/builder-style पसंद करती है, जो Rust stdlib/protos के अनुरूप है। - कुछ लोग UI/TUI builder-like APIs में fluency और consistency के लिए इसका उल्टा पसंद करते हैं।
- मार्गदर्शिका getters के लिए bare method names और setters के लिए
#[non_exhaustive]enums:- आलोचक: exhaustiveness checking को कमजोर करता है और compile-time safety को runtime bugs में बदल देता है।
- समर्थक (विशेषकर “Google scale” और distributed systems में): API evolution और बहुत-सी teams में बड़े breaking changes से बचने के लिए आवश्यक; omitted patterns को flag करने के लिए lints के साथ।
Google/Chromium-विशिष्ट प्रथाएँ
- कई छोटे crates को प्राथमिकता देना और deep module nesting से बचना:
- कारण: तेज़, अधिक parallelizable builds; finer-grained dependencies; Blaze/Bazel के साथ बेहतर cacheability (कोई incremental crate compilation नहीं)।
- Chromium Rust में फिलहाल async/await को हतोत्साहित करना।
- library और application code के बीच भेद पर ज़ोर, और उन नियमों पर जो बड़े-ट्रैफिक/बड़े-स्केल पर समान रूप से लागू हों, भले ही वे छोटे projects के लिए हमेशा “ideal” न हों।
Tooling और Naming Details
- rustfmt मौजूद है, लेकिन यह guide broader design/style concerns को भी कवर करती है।
- कुछ असहमति इस पर है कि:
- types को unqualified import करना बनाम clarity के लिए fully-qualified names का उपयोग करना।
- hex literal letter case (guide lowercase पसंद करती है) और अन्य छोटे readability tweaks।