I stopped everything and started writing C again

Why go “back” to C?

• Several commenters resonated with the attraction of C’s small surface area and “everything fits in your head” feel.
• They like that C exposes the magic instead of hiding it, forcing explicit decisions about data structures, memory, and performance.
• Some enjoy “recreational C” for the aesthetic: tiny binaries, fast compile times, and the sense of mastery.
• Others say this is more about personal “nerdiness” and learning journeys than about real performance needs.

Pain points with C in practice

• Many report that attempts to build production-grade systems in C quickly hit tedium and fragility: manual memory management, error propagation, boilerplate for data structures, and lack of language-level support for concurrency and safety.
• Build systems, dependency management, and cross‑platform issues (make/CMake, distro packaging) are frequent sources of frustration.
• Some view modern C development as “mowing the lawn with scissors”: powerful but laborious and easy to cut yourself.

Rust, Ada, Zig, Go, and others as “modern C”

• Rust is framed as addressing C’s safety problems (UB, data races, aliasing) with a much richer and more complex language and ownership model.
• There’s debate whether “fighting the borrow checker” reflects compiler limits or catching real would‑be bugs; tree structures and graph-like data remain awkward.
• Ada is mentioned as “Pascal for rockets” / “boomer Rust”: safer than C, historically tied to defense, with fewer UB cases (especially in SPARK).
• Zig is praised by C programmers as “C with polish”: explicit allocators, defer, comptime, simple semantics, but still manual memory and less safety than Rust.
• Go and Nim are cited as pragmatic, batteries‑included alternatives when GC is acceptable.

Garbage collection vs manual control

• One camp argues C-with-GC (e.g., Boehm) is “liberating” and can even improve throughput versus malloc/free, at the cost of more RAM and pauses.
• Others counter: if you accept GC overhead and unpredictability, languages like C# or higher‑level ones give far better libraries and ergonomics.
• There’s broader frustration that GC research and engineering lag far behind their potential.

C++ as “C with classes” vs sprawling complexity

• Some had great success using a restricted C++ style (plain structs/classes, little/no inheritance, minimal STL) to get RAII and templates without “galaxy‑brain” metaprogramming.
• Others say such discipline is fragile: stdlib conveniences creep in, exceptions and heap usage are hard to forbid, and language complexity inevitably seeps back.

AI-assisted coding and language choice

• Several participants now prefer Ruby or Python specifically because AI tools generate and explain those languages better; they don’t trust AI-generated C for anything serious.
• AI is seen as useful for prototypes, CRUD endpoints, and UI scaffolding, but too low-quality for critical code unless heavily reviewed and refactored.

Safety, overconfidence, and tooling

• There’s sharp disagreement over whether experienced C programmers can realistically “just stop” making memory bugs; some call such confidence dangerous.
• Others insist that with discipline, patterns, and tools (asan/ubsan/tsan, fuzzing), C can be used safely, especially in domains like embedded and kernels.
• Rust advocates argue that even top-tier C teams repeatedly ship high‑severity memory vulnerabilities, and that eliminating this entire bug class is a compelling reason to prefer safer languages.

KC3, Lisp, and learning

• Several note the article is really about creating KC3, a Lisp‑influenced language that compiles to C, not about pure C nostalgia.
• There’s agreement that learning Lisp and C both can profoundly improve how one designs and reasons about programs, even when later using other languages.