async Rust के लिए चार साल की योजना

Async “संक्रमण” और वर्कअराउंड

• बहुत से लोग शिकायत करते हैं कि अगर कोई dependency async है, तो “सब कुछ async होना चाहिए।”
• दूसरे लोग जवाब देते हैं कि आप async को अलग-थलग कर सकते हैं:
  • एक छोटा runtime शुरू करके (जैसे Tokio single-threaded, smol, pollster) और block_on का उपयोग करके।
  • async code को एक समर्पित thread पर चलाकर और channels के जरिए संचार करके।
• आलोचक कहते हैं कि इससे भी भारी runtimes और अतिरिक्त dependencies आ जाती हैं, जो build times, trust, और constrained environments के लिए महत्वपूर्ण है।

Ergonomics, complexity, और वास्तविक अनुभव

• कुछ लोगों के लिए async Rust एक बड़ा wart है: viral, intuitive नहीं, lifetime-heavy, compiler errors खराब, closures कठिन, async_trait के साथ awkward interactions।
• दूसरे लोग बड़े production codebases में वर्षों के सहज उपयोग की रिपोर्ट करते हैं, और तर्क देते हैं कि शिकायतें बढ़ा-चढ़ाकर कही जाती हैं और अक्सर सीमित या पुरानी experience से आती हैं।
• “async hard/bad है” जैसे बार-बार आने वाले arguments से थकान है, जो design की बारीकियों या linked article को अनदेखा करते हैं।

डोमेन: servers बनाम embedded और systems

• high-concurrency network services (HTTP servers, DB-heavy proxies) के लिए, बहुत से लोग कहते हैं कि predictable performance और scalability के लिए async अनिवार्य है।
• embedded और low-level systems के लिए, मतभेद हैं:
  • कुछ लोग async से पूरी तरह बचते हैं (RTOSs, actors, threads, interrupts, DMA, event loops को प्राथमिकता देते हुए)।
  • दूसरे लोग Embassy जैसे frameworks की lightweight RTOS replacement और ergonomic task structuring के रूप में प्रशंसा करते हैं।

Runtimes, Tokio का प्रभुत्व, और stdlib

• Tokio ने व्यावहारिक रूप से ecosystem “जीत” लिया है; कई crates उस पर hard-depend करते हैं (locks, channels, spawn)।
• कुछ लोग इसे सांस्कृतिक और architectural समस्या मानते हैं और चाहते हैं कि runtime-agnostic traits (AsyncRead/Write, Stream, spawn, locks, channels) std में हों।
• प्रस्तावों में शामिल हैं:
  • std में एक minimal executor या block_on (संभवतः pollster-जैसा)।
  • Tokio को default runtime न बनाना; बताया जाता है कि Rust और Tokio maintainers दोनों इसका विरोध करते हैं।

Concurrency models: threads, async, green threads

• इस पर बहस कि क्या async भाषा की feature होनी चाहिए या library/tooling की समस्या।
• कुछ लोग तर्क देते हैं कि thread-per-connection अधिकांश workloads के लिए पर्याप्त और सरल है; async मुख्यतः बहुत बड़ी संख्या में concurrent IO-bound tasks में मदद करता है।
• दूसरे लोग कहते हैं कि green threads / fibers (Go-style goroutines, Java Loom) colored async की तुलना में बेहतर DX देते हैं, बिना APIs को infect किए।
• प्रतिवाद: Rust ने पहले green threads हटाए थे; Rust की safety model और embeddability constraints के साथ उन्हें फिर से लाना trivial नहीं है।

Language design gaps और योजनाएँ

• बताए गए pain points: Pin/Unpin की complexity, async generators/iterators की कमी, async-in-traits की कमजोर कहानी (जल्द बेहतर हो रही है), async closures की ergonomics की कमी, async drop नहीं, linear/unforgettable types की कमी।
• कुछ लोग Move trait और immovable-by-default semantics चाहते हैं ताकि async सरल हो; दूसरे सतर्क हैं।
• Generators को async से निकटता से संबंधित और desirable माना जाता है, लेकिन उनका वास्तविक-world payoff बहस का विषय है।

Rust evolution की गति और governance

• कुछ लोग “glacial” stabilization की आलोचना करते हैं (जैसे block_on in std, generators, deeper async fixes), और multi-year plans की बजाय 6-month timelines चाहते हैं।
• दूसरे लोग धीमी, conservative stabilization का बचाव करते हैं क्योंकि features effectively forever होते हैं और freeze होने से पहले उन्हें सही होना चाहिए।