It seems that part of what Zig is trying to do, though, is create a pit of success around these practices. So the response might be something like, “Yes you can do these things in modern C, but doing it consistently requires more discipline than we’d like.”

https://blog.codinghorror.com/falling-into-the-pit-of-succes...

▲

uecker 2 days ago | parent | next [-]

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.

▲

2 days ago | parent | next [-]

[deleted]

▲

ProphetOfParado 2 days ago | parent | prev [-]

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.

▲

uecker 2 days ago | parent | next [-]

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).

▲

bunderbunder 2 days ago | parent [-]

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.

	▲	pjmlp 2 days ago \| parent \| next [-]
		You can also hold the line with PVS Studio, Sonar, clang tidy or similar breaking the CI/CD build when bad coding is used in C. Like the tools used for avionics development. The problem is getting the team and management to accept cowboy coding doesn't make into production.
	▲	uecker 2 days ago \| parent \| prev [-]
		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.

▲

hansvm 2 days ago | parent | prev | next [-]

The real problem is collectively agreeing about what the problem is.

▲

yawpitch 2 days ago | parent | prev [-]

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

	▲	markatto 2 days ago \| parent \| next [-]
		My heart holds fear of unintentional octal
	▲	bioneuralnet 2 days ago \| parent \| prev [-]
		One or sixteen?

▲

pjmlp 2 days ago | parent | prev | next [-]

Most of those practices were already available out of the box in languages like Object Pascal and Modula-2, or languages that predated C for a decade.

C authors created lint for similar reasons.

It has always been a social problem, getting some class of developers to actually care.

▲

slopinthebag 2 days ago | parent | prev [-]

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