It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs.
A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.
As the person you replied to said, usage by other industries. Replacement to MISRA C maybe even.
• FILE* was a big I/O abstraction that C did not have before. With Unixes and MS-DOS there were file handles, but many other platforms had nothing like that.
• That there was a clear idea of what kind of operations were well-defined was a pretty big deal. Remember, all there was before was K&R to go off as a reference, or maybe you had access to the Portable C Compiler. It was also a time where you had a lot more oddball architectures.
• void return types and parameters. There was no idea of a procedure in early C, only functions with useless return values.
And of course more. There are definitely worse cases of ISO standards than C and C++. Both are noticably better out of it.
I guess the key factor about a standard is that as a corporation you can point fingers if something goes wrong ("the compiler and/or the MISRA C checking tools you sold me are not compliant with the standard because of this bug!").
Also the committee can point fingers back if required ("the UB is clearly specified in the standard!").
If I were a team manager at a big automotive factory in charge of the ECU system, I would go the private way, with guarantees, and paying a lot of money. In case of failures, I can point fingers and someone would answer the phone on the other side if I complain.
Who should I call or who should I point my finger at, if something goes wrong because of a bug in Rust? A Github user on the other side of the planet?
I don’t think Rust or any other modern language needs to be standards-org standardized, but this is a different era; there is a single solid, well-documented, versioned reference implementation for Rust. That was never the case for C or C++.
Take the "defer" keyword in GNU C - it's valid in anything that has the GNU extensions but isn't standard C at all. And yet, some projects swear by it (it's not a bad feature, just nonstandard).
There's a lot of weirdness in C implementations even looking across LLVM, GNU, or even when picking which libc you want! Try porting any nontrivial project to work with musl-libc. You might find that it's not as easy as swapping in a target and building statically!
This is perhaps the whole rub with standardization - it's bought us as developers a lot, but it doesn't cover everything. The veil was kind of lifted for me when I started trying to use different Scheme implementations in a "standardized" way. I eventually gave up on that and just use whatever implementation I am most happy with (often CHICKEN, but that's a digression).
This gets more complicated with C++, which modern standards mostly requires C11, but then also doesn't support everything that C11 requires either. They're different languages but yeah, compilers are gonna disagree on some of the edges there.
[1] https://github.com/Rust-GCC/gccrs
[2] tangentially, Rust also avoids some UB discussion because the type system is a bit more complete in terms of its properties than C is, so they can resort to Option or Result when things get dicey in an API. Further, there's no official Rust ABI unlike C, so you don't have to worry about that either...
I teach C and C++, and you have no idea how often I hear "But it worked on my machine!" when I give back bad grades due to code that segfaults when I go to run it.
The language standards themselves state outright that programs containing undefined behaviour are malformed. If you write malformed programs, you can not assume that they are safe. Don't blame language standardization for your writing bad, unsafe software if you're not going to follow it.
In addition verifiably conformant compilers for translating your programs into software, the standard allows other tools to be written to perform things like static analysis, complexity analysis, and conformance to other published guidelines (eg. MISRA). These things are not possible where the definition of the language is "whatever one single toolchain vendor decides it will be this week".
ISO Standards are not generally required. https://news.ycombinator.com/item?id=28366670
Programming languages are tools. Governments use tools. It shouldn’t be surprising that they may have an interest.
That said I find your parent comment also a bit silly for the other reasons you state.
https://www.stroustrup.com/JSF-AV-rules.pdf
Also, when something is an ISO standard, then governments can't legislate that some countries may not be allowed to use it.
> The scenario is somewhat hyperbolic, but the US and European centric nature of Rust gives people in less developed nations pause.
This point is correct with every semi-major programming languages (top 100 popular?), so I don't think it's just a Rust problem.
If your threat model legitimately considers the US gov to be a hostile actor, you need far more than a piece of paper that claims what the behavior of your compiler is.
Even assuming that is possible, the answer is the same as any open source project: you’d have to convince the teams to make that decision. Nothing special there.
Well, for one Rust is open source, so you could download the source code and comment out the country ban yourself?
Want to catch on? Be a virus. Not some gosh-darned international standard.