I do not think it needs a lot of discipline. It needs the willingness to do it, but this is also true for adopting a different language.

Yes sir, with the right kind of discipline even assembly starts to look like luxury. With a heart that holds no fear, one can code in straight 0's and 1's.\s

These days I wonder what is harder: 1. problems of collective action or 2. communicating that reducing everything to collective action is the real issue.

If your heart holds no fear then shouldn’t that read 01 or 10?

My heart holds fear of unintentional octal

One or sixteen?

Now explain why the collective action problem of moving everybody to Zig is easier than the collective action problem of improving C usage and tooling. IMHO the latter is far more realistic (and in fact a lot has already improved).

So, suppose a team - so hopefully a rather small instance of "everybody" - has decided to make some changes to how they work, and they're trying to decide between adopting Zig and changing their existing C coding conventions.

Suppose, also, that they have decided to make the change incrementally. So a rewrite is not in the cards.

The advantage of sticking with C that I see is that nobody has to learn a new language, migrate to a new toolchain, anything like that. So it is definitely the smaller change. But the downside is that it may be more difficult to hold the line. For some indeterminate (possibly indefinite) period of time you have a mix of legacy code that's being allowed to stay on the old conventions, and new/migrated code that's supposed to be held to the new conventions. IME one solo developer can maintain that distinction, but a team working in a business environment, possibly with people cycling on and off, will struggle with it. You can try to bake the distinction into your tooling, but that's often easier said than done. Most tools expect one set of conventions per project.

The advantage of adopting Zig that I see is that you set a clear demarcation line. New files will be written in Zig. Migrated code gets ported to Zig. Everyone knows that Zig has one coding standard, C has another coding standard. They look different, so it's easy to keep track of which is which. They each have their own compiler flags and static analysis tools, so it's hopefully easier to separate the legacy rules from the new ones.

Now, I mostly do cruddy business applications so I haven't actually done this with C and Zig. But I have done it on the JVM, and IME whether "modernize legacy Java in place" or "modernize legacy Java by strangler vining over to Kotlin" works better depends heavily on what the legacy code in question actually looks like and how much you want to change.

If you change languages, you have a clear demarcation line. I still would say that if you fail to introduce stricter coding standards on a C project once you made the decision to do so, you have bigger problems that simply using other languages will not solve. So don't think this reason alone is very strong.

might as well use rust and fall into a much wider and deeper pit of success