So basically back to C89... I'm not a fan since the changes in C99 made the language significantly more convenient, more enjoyable and actually safer, and even the MSVC C frontend has a nearly complete C99 implementation since around 2015 (the parts of C99 that matter anyway).

Case in point: the article has this somewhere in the example code:

    struct struct s;
    s.member = 42;
    s.other_member = 1138;

(ignore the syntax errors and typos, the article is full of them)

If new members are added to the struct, you end up with uninitialized memory. With C99 designated init at least the new members are zero-initialized.

▲ derriz an hour ago | parent | next [-]

Your example of an uninitialized memory situation will not be so compelling for old-school C engineers because they've "solved" the issue decades ago by integrating tools like valgrind into their work-flows. They don't expect (or require) the compiler to help them deal with issues like this.

The problem with post-C89 is that you lose the unique features of old-school C.

For example, it can be compiled on basically any platform that contains a CPU. It has tool support everywhere. And it can be fairly easily adapted to run using older C compilers going back to the 1980s.

Or that (old-school) C is basically a high level assembly language is actually a feature and not a bug. It's trivial to mentally map lines of C89 code to assembly.

No other widely available language can tick these boxes.

So the problem with later versions of C is that you lose these unique features while you are now competing for mindshare with languages that were designed in the modern age. And I just don't see it winning that battle. If I wanted a "modern" C, I'll use Zig or Rust or something.

Just because a language (C89) doesn't evolve doesn't mean it's dead.

▲

flohofwoe an hour ago | parent [-]

> For example, it can be compiled on basically any platform that contains a CPU.

It will be pretty hard to find a platform which doesn't have at least a C99 compiler.

For instance even SDCC has uptodate C standard support (better than MSVC actually), and that covers most 8-bit CPUs all the way back to the 70's:

https://sdcc.sourceforge.net/

Also let's not forget that C99 is a quarter century old by now. That's about as old as K&R C was in 1999 ;)

> I'll use Zig or Rust or something.

I like Zig a lot (Rust not so much), but both Zig and Rust still have feature gaps compared to C99 which often makes me prefer C99 for day-to-day coding. Most importantly struct initalization both in Zig and Rust is very rudimentary compared to C99's designated init feature set - and somehow the authors of modern languages often don't see the benefits of having powerful data initialization features in the language. There are also lots of little paper cuts where both Zig and Rust balance convenience versus safety just a little too much away from convenience.

	▲	37 minutes ago \| parent [-]
		[deleted]

▲ hvea 2 hours ago | parent | prev [-]

Good point but as far as I know the author takes a stance against zero initialization in general.