I thought I was building a C replacement. I was wrong

The author recounts a personal journey from BASIC and Turbo Pascal through C, C++, Java, Objective-C and PHP to explain why the original pitch for C3 - as a straight “C replacement” - was mistaken. Practical experience showed that object-oriented, methods-first design often forces up-front architecture and makes later refactorings costly; procedural style yields faster, simpler development for many application tasks. C felt like the right model but its standard library and ergonomics are too minimal, while C++ carries methods-first baggage and slow compiles. C3 therefore pursued a middle path: retain C’s simplicity and performance while adding ergonomics useful for modern app development (dynamic strings/arrays, arena allocation, nicer standard utilities), and it deliberately includes some conveniences like methods for to_string while acknowledging they can reinforce a methods-first mindset.

The core realization is that “C alternative” now commonly means languages targeting C’s current domains (OS, embedded, high-performance libraries), whereas C3 was intended to be a pleasant general-purpose application language in the spirit of old-school C productivity. Marketing will shift to emphasize that C3 refreshes C for building everyday applications: simple, fast, and ergonomically improved, not merely a drop-in replacement for today’s C use-cases. Comparisons with Zig and Odin clarify trade-offs: Zig aims at replacing C where it’s used today, Odin helps instill procedural thinking, and C3 focuses on making general-purpose programming with C-like semantics more productive.