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

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.

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

comptime instead of preprocessor macros is pretty big though…

IMO you cannot fairly compare static analyzers/sanitizers with features baked into the language/compiler.

Though I've noticed the same trend when reading a famous Rust primer for C++ developers. Like there are obviously so many good and valid arguments when comparing the two languages that would've gotten the point across. Yet the authors felt the need to push it one step further, where the comparison no longer seems fair. Like comparing Rust with C++17 when C++20 provides the same exact feature that Rust claims to provide.

Where do you think the static analyzers are baked into for C?

    gcc -fanalyze ...
    clang -fsanitize=address ...
    etc

Those aren't static analyzers, they're dynamic analyzers; they only catch issues at runtime.

GCC's -fanalyze, and clang's `--analyze` both run static analyzers.

If this is such a good default, why make me type `-fsanatize=address? Why isn't this the default when not doing "release mode"?

It adds nontrivial runtime cost. It’s also not a perfect mitigation (there are plenty of unsound patterns that ASan, UBSan, and TSan won’t catch).

The obvious answer is that I don't want to pay for these checks at runtime and can catch most of these bugs at test time. There are definitely use cases where that's acceptable.

I meant static analyzers like clang-tidy and cppcheck. `-fanalyze` I suppose is a fair comparison, but `fsanitize` is not since it's not even static

Yes. Both clang and GCC come with static analyzers built in. Clangs supports whole program static analysis.

I'm very certain you can statically analyze zig's IR. And zig makes it easier to get consistency because you are steered away from the mishmash of malloc/jemalloc/pick-your-allocator-function. (The analyzer can say "all bets are off if you don't use the allocator interface") same with the new stdlib io interface for async-shaped analysis on aliasing analysis

github.com/ityonemo/clr

That works as long as you have zero dependencies.

As soon as you have dependencies you are dealing with however the authors decided to build things.

Part of why languages exist is just to get a new ecosystem.

At this point, you could fork C/C++, only remove features, give it a new name, a new package service, and maybe fork the standard library, and you could end up with something pretty competitive against Zig or Rust.

But Zig is expressly not trying to bootstrap a completely new ecosystem. Integrating with - and depending on - existing C and C++ code is a core use case. So much so that they’ve adopted “maintain it with Zig” as a motto that intentionally puns on “rewrite it in Rust”.

I don't see why this requires not having dependencies.

Yes, new languages try to create a new ecosystem. I think this is a bad thing - we already have too many of such - often somewhat isolated - language ecosystems. But I also do not think we need new ecosystems, when we can evolve the existing one. I have seen C evolve quite a bit over time, so the idea that we have to create new ecosystems to solve problems is wrong in my opinion. C evolves very slowly, which means that some things need more time, but I also think that it is generally a very good thing that it evolves slowly.

> I also think that it is generally a very good thing that it evolves slowly

This is why new ecosystems starts. Not everyone is ok with the slow pace

Not being happy with the speed is something I can understood.

But I think a fair comparison of new languages to C has to take modern C features and tooling into account.

Zig's tooling is very good, so is the cross-compatibility story and tagged unions.

But while you can have some/most of the benefits Zig has from modern C, I think an underrated benefit is the language culture. As a different language it was the opportunity for a reset, e.g. it's idiomatic Zig to pass allocators to functions, meaning every library in Zig will work this way.

You could do that in C, but none or very few libraries do that so whenever you reach out to third-party dependencies (which is not a lot, in C as in Zig) you have to fight against C's traditional patterns.

I mostly agree, but as usual there are the classical catches:

1. yeah you can do that, but we should really do some (most? all?) of the things you mention (as well as other safeguards) mandatory

2. your code might be alright, but what about your dependencies ?

There's a big difference between opt-in and opt-out features.

Because some of those tools exist since 1979, and it keeps being a quixotic battle to make corporations adopt them as standard, until cybersecurity legislation started to take off.

I think this is indeed the main problem. But it would also be the proper solution. For some the "in C/C++ this can not be fixed" narrative is a convenient excuse not to improve their code. Those parties will also not rewrite in Rust, because even with AI this more effort than zero, and zero effort is what they aim for. (and some of those parties are represented in standardization committees and vote against stricter requirements)