> The US government recently called on everyone to stop using them and move to memory-safe languages.
The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al.
Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop.
Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that.
Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.
True, but it required congressional approval to change the name then, and it would now as well.
This congress is not likely to approve it. And the next congress, even less so.
That said, "ever" is probably too strong. There's a window wherein the chaos which is currently being actively created by the US will develop to an extent that compels the US (or is sold to US voters as a necessary step) to adopt a foreign policy where it would be the more appropriate title. And if the adults can't manage that with charismatic leadership in the next election cycle or two, we could be right back here again, with quasi-legitimate geopolitical justification for the sort of big-stick wagging we see today.
I honestly think this is the goal, and I'm not sure the American people are up to the challenge of preventing it.
> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process.
DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.
I'd believe it, but from talking about this with the Ferrocene folks, there's just structural issues why it was much easier to qualify rustc than it has been to qualify C compilers. This is how they're able to offer the product at a significantly lower price point, and how they've been able to fairly regularly re-qualify new versions quickly.
> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.
Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard.
Proving it is the very hard, very expensive part.
Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.
The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al.
Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop.
Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that.
Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.