Lots of extreme generalisations and exaggerations of the situation with C. It's great that you like rust and want to write your code in it, I don't really care at the end of the day, but vague statements such are not very useful or productive.

>There's no standard for building C programs.

Is there a written standard for compiling rust programs? I don't think so. Rust doesn't do standards after all.

Jokes aside, this is basically irrelevant. Why does there need to be a standard for building C programs? Making something build across platforms (including cross compilation to other platforms) has been solved by everyone and their grandmother at this point. This means that aside from taking the route of re-implementing it yourself (not particularly difficult) you have literally dozens of perfectly good options to chose from.

In fact, most of this rant sounds like it stems from your dislike of OpenMP not C.

>I could have kept the library in C and replaced OpenMP with some other solution instead, but I wasn't keen on reinventing this wheel. Even basic things like spawning a thread run into C's portability woes.

Thankfully, you don't need to reinvent the wheel, the problem of cross platform multiprocessing in C has been solved at least a dozen times by now. It should be trivial to use one of these many options (or even write your own, even if you don't like the idea of "reinventing the wheel" it's certainly not particularly difficult either and can likely be lighter than any other more general option).

>The platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess of vendor-specific toolchains, each with its own way of doing things, missing features, broken headers, and leaky abstractions. Shouting "it's not C's fault, screw !" doesn't solve the problem, but switching to Rust does.

I mean, rust is hardly helping you here. There's one implementation of rust doing their own thing so far, nothing stops anyone from making this situation as "bad" as in C. You may as well just say you only support clang or only support GCC and base your project around that assumption. In fact, if you're making the mistake of trying to support a microsoft compiler then I would argue that you've made your life difficult for no reason and blamed it on C.

>dreadful state of C dependency management did.

Hardly any more dreadful than rust's solution to the problem.

I disagree about dependency management. Let's say, to avoid reinventing the wheel, I decided to use GLib for cross-platform threading. How do I add GLib as a dependency to my C project? Now compare it to adding Tokio as a dependency to my Rust project, which is entirely trivial.

> How do I add GLib as a dependency to my C project?

Use symbol versioning.

Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased.

As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.

I don't think that fragmentation is a given.

Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C.

But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is.

[1]: https://lib.rs/stats

Ye that is true (isn't Java a bad example though with Google-Java, OpenJdk vs BigEnterpriseJdk etc?).

Furthermore, there are big difference in philosophy with C:

1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications

2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations

Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging.

Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec).