Zig, Rust, और अन्य भाषाएँ

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

Zig का allocation मॉडल और “कोई छिपा हुआ allocation नहीं”

  • कई टिप्पणियाँ लेख के इस मजबूत दावे से असहमत हैं कि Zig hidden allocations से बचता है।
  • Standard C functions अधिकांशतः allocate नहीं करतीं; strdup एक उल्लेखनीय अपवाद है।
  • Zig में, ज़्यादातर stdlib APIs “अगर इससे allocate हो सकता है तो allocator पास करो” वाली परंपरा का पालन करती हैं, लेकिन सभी नहीं:
    • std.Thread.spawn explicit allocator के बिना भी allocate करता है (argument payload के लिए stack + heap)।
    • std.ArrayList अपने भीतर allocator स्टोर करता है, इसलिए method calls बिना allocator पास किए भी allocate कर सकती हैं।
    • ArrayListUnmanaged इसलिए मौजूद है ताकि allocators को उच्च स्तर पर रखा जा सके और allocations स्पष्ट रहें।
  • कुछ लोग इसे एक सख्त guarantee के बजाय “सिर्फ एक convention” मानते हैं; दूसरे कहते हैं कि यह फिर भी उपयोगी है।

भाषाओं के बीच memory management trade-offs

  • Nim को एक systems language के रूप में highlighted किया गया है, जिसमें configurable memory management है; default ARC को Zig code में allocators को हर जगह thread करने की तुलना में अधिक ergonomic माना जाता है।
  • प्रतिवाद: Zig में global allocator का उपयोग किया जा सकता है या objects के साथ allocators जोड़े जा सकते हैं, ताकि अनावश्यक plumbing से बचा जा सके।
  • Odin, अच्छे APIs और arenas के साथ C, और अन्य उदाहरणों का हवाला देकर तर्क दिया गया कि API design स्वयं भाषा से अधिक महत्वपूर्ण है।

Standard library का आकार बनाम ecosystem fragmentation

  • एक पक्ष compact stdlibs को पसंद करता है ताकि C++-style bloat से बचा जा सके, तेज़ evolution सक्षम हो, और पुरानी APIs के दीर्घकालिक maintenance को कम किया जा सके।
  • दूसरा पक्ष तर्क देता है कि छोटी stdlibs कई third-party packages पर निर्भरता बढ़ाती हैं, जिससे fragmentation, कई प्रतिस्पर्धी libraries, और dependency hell पैदा होता है।
  • उदाहरण:
    • Python: बड़ी stdlib को सामान्यतः सकारात्मक माना जाता है, हालांकि कुछ modules पुराने हैं; लोकप्रिय third-party libs (जैसे HTTP clients) फिर भी ergonomics में आगे रहते हैं।
    • Go: stdlib की प्रशंसा की जाती है, लेकिन कुछ हिस्सों (logging, flags, पहले का net.IP) की आलोचना होती है; netip जैसी नई abstractions सुधार लाती हैं।
    • Rust: stdlib में compression का न होना इस रूप में बचाव किया जाता है कि evolving domains को crates में रखा जाए; दूसरे लोग अन्य ecosystems की stdlibs में अच्छे compressors को counter-evidence के रूप में देखते हैं।
  • सुझाया गया समझौता: छोटी core stdlib + आधिकारिक रूप से maintained “blessed” packages, या बाद में de-facto standards को अपनाना।

Package managers और dependency संबंधी चिंताएँ

  • Zig की package story:
    • build.zig.zon और git references के माध्यम से package management उपलब्ध है; आगामी 0.12 सुधारों की अपेक्षा की जा रही है।
    • Go की तरह, डिज़ाइन के अनुसार कोई केंद्रीय package repository नहीं है; कुछ इसे सुरक्षित मानते हैं, तो कुछ इसे गलत निर्णय।
  • सामान्य चिंताएँ:
    • कई प्रतिस्पर्धी C/C++ package managers (vcpkg, conan, आदि) आपस में ठीक से interoperate नहीं करते।
    • Rust का cargo:
      • प्रति-project source duplication से बचता है; dead code elimination binary bloat को कम करती है।
      • जिन समस्याओं का उल्लेख किया गया: बड़े caches और stale incremental artifacts; nightly पर आने वाला automatic cache GC स्वागतयोग्य माना गया है।
    • कुछ लोग language-specific managers के बजाय Nix का उपयोग सुझाते हैं।

Strings, Unicode, और type-system guarantees

  • Zig:
    • strings के लिए []const u8 का उपयोग करता है; परंपरा के अनुसार ये UTF-8 होते हैं।
    • Functions अक्सर runtime checks के बिना valid UTF-8 मान लेती हैं; जिम्मेदारी producer पर होती है।
    • आलोचक इसे “बस bugs मत लिखो” जैसा मानते हैं और encodings/invariants को types में व्यक्त करने की वकालत करते हैं।
  • Rust:
    • String (owned UTF-8) और &str (borrowed UTF-8) में भेद करता है, safe code में runtime UTF-8 validation के साथ।
    • Unsafe constructors checks को तभी छोड़ने देते हैं जब programmer validity की गारंटी दे।
    • OsString जैसे अलग types UTF-8 थोपने से बचाते हैं जहाँ इसकी गारंटी नहीं होती।
    • इस model की सुरक्षा और flexibility के लिए प्रशंसा होती है, लेकिन complexity और सीखने के बोझ के लिए आलोचना भी।
  • Go और अन्य:
    • Go string “सिर्फ bytes” है; इसमें arbitrary data हो सकता है, UTF-8 की गारंटी नहीं।
  • Unicode support:
    • Zig का std.unicode validation और codepoint iteration को कवर करता है; अधिक उन्नत support (graphemes, categories) external libraries में है।
    • इसी तरह की कमियाँ Rust और Go में भी हैं; पूर्ण Unicode handling (जैसे grapheme iteration, locale-aware sorting) जटिल है और अक्सर libraries को सौंपी जाती है।
  • कुछ लोग तर्क देते हैं कि क्योंकि “string” की आवश्यकताएँ बहुत विविध हैं (mutability, slicing, Unicode semantics, performance), इसलिए ecosystems में कई string abstractions का विकसित होना स्वाभाविक है, भले ही एक built-in type मौजूद हो।