कर्नेल कोड के लिए Rust अपनाने का संकल्प

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

Linux द्वारा kernel development में Rust को अनुमति देने से इस पर बहस छिड़ गई है कि क्या यह कुछ लंबे समय से चले आ रहे C कोड, खासकर drivers में जहाँ memory safety bugs आम हैं, को सुरक्षित और कुशलतापूर्वक बदल सकता है। समर्थक Rust के ownership model, मजबूत static checks, और no_std क्षमताओं को प्रदर्शन से समझौता किए बिना सुरक्षित systems programming के लिए शक्तिशाली उपकरण मानते हैं, जबकि आलोचक धीमे compile times, `unsafe` code की जटिलताओं, और LLVM तथा C++ पर toolchain निर्भरताओं को लेकर चिंताएँ जताते हैं। Zig जैसे विकल्पों का उल्लेख “C culture” के अधिक निकट दार्शनिक रूप से होने के कारण किया जाता है, लेकिन Rust की अपेक्षाकृत परिपक्वता और low-level systems में मौजूदा production उपयोग इसे kernel में incremental adoption के लिए प्रमुख उम्मीदवार बनाते हैं.

C→Rust माइग्रेशन के अनुभव

  • माइग्रेशन करने वालों का कहना है कि Rust डेटा ownership, lifetimes, और “multiple readers, one writer” पैटर्न के बारे में गहराई से सोचने के लिए मजबूर करता है।
  • यह बदलाव बाद में C में लिखते समय भी डिज़ाइन को बेहतर बनाता है।
  • Result/Option और match के जरिए error handling, inline tests, और documentation tooling को बड़ी productivity जीत माना जाता है।
  • कई लोग दावा करते हैं कि Rust codebases काफी अधिक concise होते हैं और अपने C समकक्षों की तुलना में कम brittle महसूस होते हैं।

Dynamic Data और JSON Handling

  • कुछ लोगों का कहना है कि Rust highly dynamic tasks (जैसे runtime JSON schemas, unknown DB tables) को dynamic languages की तुलना में “थोड़ा कठिन” बना देता है।
  • अन्य लोग तर्क देते हैं कि यह ज़्यादातर extra verbosity है, कोई वास्तविक सीमा नहीं, और runtime JSON-schema validation के लिए मौजूद crates की ओर इशारा करते हैं।

Compile-Time Performance

  • शिकायतें: C की तुलना में Rust compile times “भयानक” हैं और उपयोग से हतोत्साहित कर सकते हैं।
  • प्रतिवाद:
    • मध्यम आकार के प्रोजेक्ट्स के लिए, clean builds सामान्य laptops पर कुछ मिनटों में पूरे हो जाते हैं।
    • C++ की तुलना में, समान features उपलब्ध होने पर Rust अक्सर उतनी ही तेज़ या उससे तेज़ compile होता है।
    • भारी dependency trees और traits/macros compile times को सबसे अधिक नुकसान पहुँचाते हैं; kernel Rust (no_std, कम dependencies) को इससे बेहतर स्थिति में होना चाहिए।
  • Rust और C coreutils की तुलना करने वाले benchmarks दिखाते हैं कि setup work को कैसे गिना जाता है, इस पर निर्भर करते हुए build times लगभग 2× factor के भीतर हैं।
  • तर्क दिया गया कि केवल monomorphization मुख्य दोषी नहीं है; नाटकीय सुधार के लिए भाषा डिज़ाइन में मूल रूप से अलग दृष्टिकोण की आवश्यकता होगी।

Kernel और Systems Programming में Rust

  • प्रबल उत्साह: Rust की memory safety को drivers के लिए महत्वपूर्ण माना जाता है, जहाँ concurrency bugs और unsafe patterns व्यापक हैं।
  • यह साक्ष्य उद्धृत किया गया कि kernel में memory-safety bugs ठीक होने की तुलना में तेज़ी से जोड़े जा रहे हैं; Rust को एक संरचनात्मक mitigation के रूप में प्रस्तावित किया गया है।
  • संशयवादी:
    • bare metal और ultra–low-latency systems के लिए Rust की उपयुक्तता पर सवाल उठाते हैं, और C++-आधारित LLVM पर निर्भरता को नापसंद करते हैं।
    • कुछ लोग Zig को C के सांस्कृतिक रूप से अधिक निकट और बड़े toolchain dependencies के प्रति अधिक hostile मानते हैं, लेकिन स्वीकार करते हैं कि Zig अभी पर्याप्त स्थिर नहीं है।
    • Rust में low-latency trading का एक प्रयास बताता है कि अंतिम, performance-critical 20% को safe Rust में बेहद कठिन पाया गया; unsafe C की तुलना में अधिक खतरनाक महसूस हुआ।
  • समर्थकों का उत्तर है कि:
    • अधिकांश low-level काम को छोटे unsafe sections में अलग किया जा सकता है, जबकि बाकी को safety का लाभ मिलता है।
    • Rust C-जैसे abstraction levels पर काम कर सकता है (विशेषकर no_std के साथ), और साथ ही उपयुक्त होने पर high-level, zero-cost abstractions की अनुमति भी देता है।

Toolchains और LLVM/GCC

  • kernel को increasingly Clang के साथ build किया जा रहा है; bugs बने हुए हैं, लेकिन toolchain competition को लाभकारी माना जाता है।
  • कुछ लोग शिकायत करते हैं कि GCC/binutils/glibc के बिना LLVM बनाना कठिन है; अन्य लोग तर्क देते हैं कि यह एक niche चिंता है और ध्यान दिलाते हैं कि GCC भी C++ पर निर्भर करता है।