Rust Glancer: Rust LSP जो RAM का 100x कम उपयोग करता है

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

एक नया Rust भाषा सर्वर, Rust Glancer, RAM उपयोग को बहुत कम करने का लक्ष्य रखता है: यह अधिकांश analysis data को disk पर offload करता है और हर query के लिए केवल ज़रूरी चीज़ें लोड करता है, जबकि rust-analyzer का मॉडल हमेशा-in-memory और पूरी तरह incremental है। Commenters बताते हैं कि rust-analyzer बड़े workspaces में नियमित रूप से कई gigabytes RAM खा सकता है, और यह बहस भी होती है कि projects और proc-macro उपयोग बढ़ने के साथ उसका मूल “disk cache नहीं, तेज analysis को मजबूर करो” वाला दर्शन अभी भी उचित है या नहीं। Thread में latency, indexing strategies, on-disk formats, proc macros और additional editors के लिए भविष्य के समर्थन, तथा coding aids के रूप में LLMs के सतर्क लेकिन व्यावहारिक उपयोग जैसे tradeoffs पर भी चर्चा होती है—“brain replacements” के रूप में नहीं।

प्रोजेक्ट के लक्ष्य और आर्किटेक्चर

  • Rust Glancer एक Rust भाषा सर्वर है जो अधिकतर विश्लेषण डेटा RAM के बजाय डिस्क पर रखता है।
  • यह एक पूर्ण, non-incremental प्रारंभिक index करता है, फिर प्रत्येक query के लिए केवल ज़रूरी डेटा memory में लोड करता है।
  • खुले buffers को प्राथमिकता दी जाती है; बाकी सबका background में indexing होता है।
  • save करने पर, यह पूरे project के बजाय केवल प्रभावित crate(s) को reindex करता है; dirty buffers अंतिम semantic snapshot के ऊपर एक हल्के syntax overlay का उपयोग करते हैं।

Memory usage और performance tradeoffs

  • लक्ष्य है “reasonable projects” के लिए “<100 MB,” हालांकि initial indexing के दौरान यह rust-analyzer (RA) से थोड़ी देर के लिए अधिक RAM उपयोग कर सकता है।
  • peak cost अधिकतर प्रति project एक बार, या जब dependencies / toolchains बदलते हैं, तब चुकाया जाता है।
  • इसके बदले idle usage कम रहता है, restarts सस्ते होते हैं, और RA के हमेशा-hot incremental approach की तुलना में CPU ठंडा रहता है।
  • on-disk artifacts project के size के साथ scale करते हैं (उदाहरण के लिए Rust Glancer खुद के लिए ~225 MB)।

Disk caching बनाम incremental in-memory analysis

  • कई commenters शिकायत करते हैं कि RA कई GiB से लेकर tens of GiB तक consume कर सकता है, खासकर multiple workspaces में।
  • कुछ का तर्क है कि RA को disk का अधिक आक्रामक रूप से उपयोग करना चाहिए (जैसे mmap’d structures या RocksDB-backed cache)।
  • एक विस्तृत जवाब बताता है कि RA ने शुरू में disk से जानबूझकर दूरी बनाई थी ताकि:
    • इतिहास के IDE caches में देखी गई complexity और corruption समस्याएँ कम हों।
    • fast, lazy, in-memory analysis और अच्छे startup times को मजबूर किया जा सके।
    • persistence-first के बजाय IDE architecture prototyping पर ध्यान रहे।
  • प्रस्तावित “middle ground”: dependencies के लिए compact on-disk indices और active workspace के लिए lazy incremental in-memory backend, जिसमें files editable होने पर switch करने की क्षमता हो।

Proc macros और extensibility

  • Rust Glancer future release के लिए proc macros हेतु plugin/DSL के माध्यम से “describe effects, don’t execute code” मॉडल की योजना बना रहा है।
  • उद्देश्य LSP में arbitrary code execution से बचना है, जबकि externally visible macro effects को फिर भी model किया जा सके।

Editor support और UX

  • आने वाले releases में Neovim और Zed का समर्थन करने का लक्ष्य है; LSPs को अभी भी प्रति-editor छोटे adapters की आवश्यकता होती है।
  • Auto-imports और “find references” को भारी features माना गया है और पूरी तरह enable करने से पहले इन्हें optimize किया जा रहा है।

विकास में LLM का उपयोग

  • लेखक LLMs को assistants मानता है: domain knowledge के लिए अच्छे, architecture के लिए कमजोर।
  • जिन pitfalls का उल्लेख किया गया है: code का bloated होना, functionality का duplicate होना, refactors का विरोध करना, और अनावश्यक confidence के साथ बोलना।
  • अन्य लोगों ने तेज़ी से सरल LSPs बनाने जैसे सकारात्मक अनुभव भी साझा किए और over-reliance पर चिंताएँ भी जताईं।

Acronyms और audience

  • इस पर बहस हुई कि “LSP” जैसे terms को हमेशा expand किया जाना चाहिए या नहीं।
  • एक पक्ष: inclusive होने के लिए acronyms हमेशा समझाए जाने चाहिए।
  • दूसरा पक्ष: programmer-focused forum पर Rust/LSP जैसे terms सामान्यतः ज्ञात माने जाते हैं; चाहें तो पाठक उन्हें देख सकते हैं।