I'm too dumb for Zig's new IO interface

Original Article ↗ Hacker News Discussion ↗

New IO Interface & Buffer-Passing

  • Several commenters struggle with the new Reader/Writer/Stream layering: converting between types (interface() vs &interface) feels inconsistent and under-documented.
  • Requiring users to allocate and pass buffers is defended as enabling buffer pools, static allocation, and tighter control over allocation; critics note most users just want “read/write bytes” and now pay complexity for a minority’s needs.
  • Suggestions include dual constructors (simple one that allocates internally; advanced one that accepts buffers) and clearer conventions for when to flush and how streaming vs non-streaming modes interact.
  • The article’s author reports eventually succeeding but only after double-flushing and understanding hidden behavior around sendFile, reinforcing the “too clever, not explained” criticism.

Stdlib Churn, Documentation, and Pre‑1.0 Reality

  • Many see the IO changes as emblematic: powerful but landing with weak docs, few examples, and reliance on “read the stdlib source” or test code.
  • Some defend this as inevitable in a fast-moving, pre‑1.0 language with a small team; others argue that lack of even minimal, high-level docs is a serious barrier and a design smell.
  • There’s debate whether writing docs “later” is acceptable: one side says churn would make docs obsolete; the other says documentation is how you discover bad APIs and onboard contributors.
  • Multiple users are postponing upgrades (or sticking to OS APIs via cImport) until IO and the build/package story settle.

Safety, Memory Management, and Tradeoffs

  • Large subthreads debate memory safety vs performance:
    • Zig is seen as safer than C/C++ (bounds checks, checked casts, better defaults, debug allocators) but intentionally does not guarantee use-after-free freedom.
    • Some argue all new languages should be fully memory-safe; others contend that temporal safety has real costs (complexity, compile times, ergonomics) and may not be worth it for Zig’s target domain.
  • Long digressions compare tracing GC vs manual/arena allocation, with disagreement over when GC’s RAM/CPU tradeoff is economically optimal.

Positioning: Zig vs C, C++, Rust, Go, etc.

  • One camp views Zig as a “love letter to C” and a niche systems language: ideal when you’d otherwise use C, thanks to better enums/tagged unions, error handling, defer, comptime, cross-compilation, and simpler tooling.
  • Critics say it doesn’t address the core pain of C++ (safety, complexity) as effectively as Rust/Swift and remains “just another unsafe language,” so unlikely to displace higher-level ecosystems.
  • Others emphasize that Zig’s goals are low-level, data-oriented, near-metal work, not competing with Java/JS/Python; being memory-unsafe is seen as an explicit tradeoff, not an oversight.

Community Culture & Language Wars

  • Some perceive a strong anti-Rust and anti-“beginner” undercurrent in the Zig ecosystem, contrasting it with Rust’s heavy investment in onboarding and docs.
  • Others insist Zig itself isn’t anti-Rust, but acknowledge that frustration with Rust and C++ has driven part of its following, and that pre‑1.0 instability plus this culture naturally select for “hardcore” users.