C isn't a programming language anymore (2022)

Original Article ↗ Hacker News Discussion ↗

C as legacy, context, and active tool

  • Several view C like Latin or Roman law: essential to learn for historical context and understanding later developments, but less often used directly.
  • Others push back, noting substantial ongoing proprietary and embedded C code, and argue there’s still more low-level C than Rust.
  • Some agree with the article’s framing of C as primarily an API/ABI now, less a language people “practice,” but reject continual C‑bashing as beating a “dead horse.”

Stability, durability, and alternatives

  • Pro‑C commenters emphasize its long-term stability (e.g. C99) and “serviceability”: you can work productively with decades-old code, akin to tradespeople working on old houses.
  • Critics counter that modern alternatives (Rust, others) evolve fast but bring safety and better tooling, even if idioms and toolchains churn.
  • HTTP/JSON is suggested as the real “replacement” for C for most modern software (out-of-process), with C remaining mainly in OS and low-level stacks.

C as de facto ABI and interoperability layer

  • Central thesis defended by several: C is no longer just a language but the dominant in‑process interoperability protocol; anyone doing FFI must care about C and its ABIs.
  • This is seen as accidental rather than deliberately designed for multi-language interoperability, leading to pain around headers, “wobbly” types, and underspecified ABIs.
  • Some argue an explicit language‑agnostic ABI + IDL (e.g., COM‑like) would be better; others note such systems exist but are complex and unpopular.
  • System V ABI is seen as an imperfect but necessary lingua franca; replacing it would require contentious standardization and likely produce new complaints.

Why C “won” and its relation to hardware

  • One line: C minimally reflects how computers work, gives “escape hatches,” and trusts the programmer, unlike more restrictive Pascal/Ada.
  • Another: C mainly rode Unix’s and OS vendors’ coattails; if another platform had dominated, a different language might have.
  • Debate over whether C still meaningfully reflects hardware: some say it matches an abstract machine, not modern CPUs; issues like pointer provenance and lack of SIMD/AVX modeling are cited.

Design flaws, types, and errors

  • Common complaints: unspecified integer sizes, arrays decaying to pointers, null-terminated strings, lack of size info in APIs, weak type system, clumsy macros, and a hard-to-master standard.
  • Others defend intent-based types (size_t, ptrdiff_t, etc.) over fixed-width types, and praise C-style manual error handling for explicitness and forward compatibility.
  • There is agreement that fixed-width types and aliasing semantics arrived late and legacy APIs still rely on older, less precise conventions.

Meta and tone

  • Some find the article “whiny” or attribute it to frustration porting C code to Rust/Swift; others call that ad hominem and reiterate that the point is about C-as-protocol, not C’s worth as a language.
  • A few note that any replacement ABI would inherit similar compromises; C’s role is seen as historically contingent yet deeply entrenched.