.NET 8 लिनक्स पर 50% छोटा स्टैंडअलोन

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

.NET 8 का native AOT tooling अब लिनक्स पर बहुत छोटे standalone binaries बनाता है, जिससे serverless workloads, containers, और cross‑platform CLI tools के लिए C# में नई रुचि पैदा हुई है। टिप्पणीकार AOT compatibility के लिए reflection और source generators से जुड़े trade-offs पर चर्चा करते हैं, .NET की concurrency, performance, और memory use की Go और Java से तुलना करते हैं, और cloud तथा on-prem environments में Linux पर .NET चलाने के व्यापक production अनुभव साझा करते हैं। उत्साह के बावजूद, fragmentation या “half-finished” official libraries, Linux पर कमजोर first-party GUI support, और Microsoft के दीर्घकालिक stewardship को लेकर चिंताएँ बनी रहती हैं, हालांकि तकनीकी प्रगति मजबूत है.

Native AOT, आकार और प्रदर्शन

  • चर्चा .NET 8 native AOT स्टैंडअलोन बाइनरीज़ पर केंद्रित है, जो “hello world” के लिए लगभग 2 MB और लिनक्स पर पहले की तुलना में लगभग 50% छोटी बताई जा रही हैं।
  • स्पष्ट किया गया कि यह native AOT पर लागू होता है; सामान्य .NET ऐप्स अभी भी JIT का उपयोग करते हैं, हालांकि trimming में सुधार हुआ है।
  • AOT को मुख्यतः तेज़ cold starts और serverless/container परिदृश्यों में छोटे images के लिए महत्व दिया जाता है (जैसे AWS Lambda, Azure Functions)।

Reflection, Source Generators और AOT की सीमाएँ

  • AOT पर भारी reflection और runtime code generation की सीमाएँ लागू होती हैं; इनके लिए वैकल्पिक तरीकों की आवश्यकता होती है।
  • कुछ लोगों का मानना है कि reflection का उपयोग समय के साथ source generators और interceptors के माध्यम से घटेगा; दूसरों का तर्क है कि reflection बहुत सुविधाजनक है और generators बहुत जटिल, इसलिए दोनों साथ-साथ बने रहेंगे।

लिनक्स पर .NET का अपनाना और अनुभव

  • कई लोग बताते हैं कि वे नियमित रूप से लिनक्स पर .NET चलाते हैं: Kubernetes, Docker, AWS Lambda, Azure App Service (Linux), cloud VMs, self-hosted servers, और homelab apps (जैसे Jellyfin, *arr apps, Ethereum client)।
  • कई टीमें production में Linux उपयोग करती हैं जबकि developers Windows/macOS पर काम करते हैं; अन्य पूरी तरह macOS/Linux पर Rider, VS Code, या Neovim के साथ development करते हैं।
  • कई web APIs और function apps के लिए, Linux अब default deployment target है; Windows की तुलना में license savings इसका बड़ा कारण हैं।
  • .NET Framework से migration कुछ लोगों के लिए अब भी एक दर्द बिंदु है, जिससे कुछ संगठनों ने Java की ओर रुख कर लिया।

टूलिंग और इकोसिस्टम

  • C#/.NET की productivity, performance, और tooling की जोरदार प्रशंसा हुई है (खासकर Rider; VS को भारी और कभी-कभी नाज़ुक माना गया, हालांकि कुछ का कहना है कि इसमें सुधार हुआ है)।
  • Microsoft की “official” libraries पर राय बंटी हुई है: Entity Framework Core की अक्सर प्रशंसा होती है, OData की व्यापक रूप से आलोचना; कई लोग MS stacks की बजाय हल्के OSS tools (Dapper, Postgres, Redis) सुझाते हैं।
  • कुछ लोगों की शिकायत है कि MS समुदाय के OSS को अपनाने के बजाय उससे “प्रतिस्पर्धा” करता है, जिससे ecosystem को नुकसान होता है।

भाषा तुलना (Go, Java, F#, आदि)

  • Go बनाम C# पर बहस:
    • Go के पक्ष में: सरल, async “coloring” के बिना first-class concurrency, cloud infrastructure के लिए अच्छा।
    • C# के पक्ष में: अधिक समृद्ध type system, शक्तिशाली async/await, tasks, channels, अक्सर बेहतर throughput; कुछ का दावा है कि Go का GC और concurrency बेहतर नहीं हैं।
  • इस बात पर असहमति है कि C# के दिखाए गए concurrency उदाहरण वास्तव में “concurrency” हैं या “parallelism।”

GUI और Linux सपोर्ट

  • एक बड़ी निराशा: MAUI में आधिकारिक Linux GUI support नहीं है, जबकि cross-platform को लेकर मजबूत push है।
  • कुछ लोग मानते हैं कि Avalonia/Uno पर्याप्त अच्छे हैं; अन्य लोगों के लिए first-party Linux GUI की कमी Microsoft की desktop apps के लिए Linux के प्रति प्रतिबद्धता पर चिंता का संकेत है।

अन्य तकनीकी नोट्स

  • परीक्षणयोग्यता के लिए TimeProvider और FakeTimeProvider का स्वागत किया गया; FileSystemProvider की इच्छा भी व्यक्त की गई।
  • Native AOT के साथ static linking अब संभव है, जिसमें .NET libraries को native projects में link करना भी शामिल है।
  • Azure Functions on Kubernetes with KEDA को DIY serverless विकल्प के रूप में उल्लेख किया गया।