Linux 0.11 को idiomatic Rust में फिर से लिखा गया, QEMU में बूट करता है

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

एक शुरुआती Linux 0.11 kernel को idiomatic Rust में फिर से लिखा गया है और उसे QEMU में बूट कराया गया है, जिससे code size, readability, और यह बहस छिड़ गई है कि क्या Rust की safety और abstractions अतिरिक्त जटिलता को सही ठहराती हैं। कई लोगों को संदेह है कि बड़े हिस्से AI द्वारा जनरेट किए गए थे, जिससे ऐसे rewrites की educational value, authenticity, और long-term maintainability पर सवाल उठते हैं। व्यापक रूप से, टिप्पणीकार LLM सहायता से मौजूदा C और Zig codebases को “Rust-ify” करने की बढ़ती प्रवृत्ति पर बहस कर रहे हैं, जहाँ memory safety और modernization की तुलना hype, tooling dependence, और सांस्कृतिक थकान से की जा रही है।

रीराइट का दायरा और लाइन काउंट

  • टिप्पणीकारों का कहना है कि Rust repo में मूल C स्रोतों की तुलना में कहीं अधिक लाइनें हैं (शुरुआत में लगभग 50k बनाम ~8–12k SLOC)।
  • अन्य लोग यह इंगित करते हैं कि:
    • एक ब्रेकडाउन दिखाता है कि कर्नेल के लिए लगभग 15k लाइनें हैं; बाकी टूल्स, यूटिलिटीज़, और userland programs हैं।
    • Rust में comments, tests, और अतिरिक्त abstractions आकार में योगदान देते हैं।
    • verbosity के अंतर पर बहस है: कुछ लोग Rust को अधिक explicit/verbose मानते हैं, जबकि अन्य कहते हैं कि समान कार्यक्षमता के लिए यह C जितना concise या उससे भी छोटा हो सकता है।

AI की भागीदारी और “slopware” संबंधी चिंताएँ

  • कई टिप्पणीकारों को संदेह है कि बड़े हिस्से किसी LLM द्वारा जनरेट किए गए थे (README शैली, emojis, और “idiomatic abstractions” भाषा के आधार पर)।
  • कुछ लोग इसे स्वीकार्य, या यहाँ तक कि आदर्श मानते हैं, एक toy / proof-of-concept project के लिए जिसे production में कोई नहीं चलाएगा।
  • अन्य लोग AI-जनित “token projects” से निराश हैं, उन्हें कम मेहनत वाली self-promotion मानते हैं और मानव-लिखित rewrites की तुलना में कम प्रभावशाली समझते हैं।
  • चिंता यह है कि AI rewrites अक्सर असुरक्षित patterns को बस “unsafe Rust” में ले जाते हैं, बिना वास्तविक सुरक्षा लाभ के।

Rust की idiomaticity, readability, और safety

  • कुछ टिप्पणीकारों को Rust fork implementation विशेष syscalls के लिए C के समान या उससे भी छोटी लगती है, जैसे fork।
  • अन्य लोग Rust संस्करण की आलोचना “onerous” कहकर करते हैं:
    • कई लाइनें core logic के बजाय abstractions, error handling, या भाषा की सीमाओं के लिए होती हैं।
    • nested closures और complex type inference का भारी उपयोग readability को नुकसान पहुँचाता है और मजबूत tooling की आवश्यकता पैदा करता है।
  • समर्थकों का तर्क है कि Rust के explicit enums, types, और borrow checking बगों की कई श्रेणियों को कम करते हैं और rewrites को सही ठहरा सकते हैं।

प्रोजेक्ट का उद्देश्य और मूल्य

  • इसे व्यापक रूप से toy / educational / proof-of-concept प्रयास माना गया है (आज Linux 0.11 व्यावहारिक रूप से उपयोगी नहीं है)।
  • कुछ लोग इसमें मूल्य देखते हैं:
    • यह दिखाना कि kernel को “Rustified” किया जा सकता है।
    • AI-assisted बड़े rewrites और workflows का अन्वेषण करना।
  • अन्य लोग तर्क देते हैं कि यदि LLM ने coding का अधिकांश हिस्सा किया, तो educational value खो जाती है।

Rust और LLM के खिलाफ व्यापक प्रतिक्रिया

  • कई टिप्पणियाँ इस थकान को व्यक्त करती हैं कि:
    • लगातार “X rewritten in Rust” घोषणाएँ।
    • Rust evangelism और AI-generated rewrites का संयोजन।
  • विरोधी बिंदु यह जोर देते हैं:
    • unsafe C को बदलने में Rust की बढ़ती भूमिका, जिसमें userland और kernels भी शामिल हैं।
    • experimentation और “fun” side projects को फिर भी प्रोत्साहित किया जाना चाहिए।