4 ms·

Not really. Source: I use Rust in automotive where MISRA C is required, and the only thing we needed was to certify it. No ISO standard required. We actually

Not really. Source: I use Rust in automotive where MISRA C is required, and the only thing we needed was to certify it. No ISO standard required. We actually also supplied a "fork" of the MISRA C doc, crossing out ~80% of it, since it was just stuff that is just not possible in safe Rust. We covered the remaining 20% with clippy lints. Most of the certification involved is just basic stuff like "using version control system", "has unit test", "tests run on changes", "uses a linter" (really, as vague as just that...), etc. We tried to explain that we used "miri" to run most of our integration tests on top of an interpreter that detects all undefined behavior, but the current safety processes don't even have a concept for this, so we had to left this point out to pass certification (we still do it, it's just not something that's accounted for). The process allows us to use crates.io crates "as is", even those with "unsafe code", as long as these have tests and we run them with our clippy linters enabled. Basically, you just need to pay an entity to say that you don't have absurdly horrible software practices. That's where C and C++ have set the bar, and this bar is absurdly easy to meet with Rust, given that it has support for unit tests, most code available already has tests, has a linter built in, etc.

pjmlp 5y ago
Good it is working for you, although I think it depends how burocratic the customer and government departments might be in each specific project.
- volta83 5y ago
  There are many levels of certification. This project is in Central Europe. A different team uses it in satellite micro controllers in the US, but I am not involved with that. I don't know of any safety certification process that requires the programming language to have an ISO standard specification.
  - pjmlp 5y ago
    Thanks for sharing, I don't mean that they have, more from burocratic point of view, like checklists in RFPs, given conformance with stuff like these https://www.highintegritysystems.com https://www.highintegritysystems.com > Supports IEC 61508, IEC 62304, FDA 510K Hence why imagine Rust might need some kind of good for high integrity computing stamp, be it ISO, ECMA, or something else.
    - volta83 5y ago
      I think what's useful would be to have someone certify the Rust toolchain for some of these. That's what's needed to enable anyone to develop safety critical apps without issues. The problem is that most certification consultancies don't allow you to publish a certification such that everyone can use it. That puts them out of work. The ones that have already certified Rust, make an upfront investment in the certification, and then can certify more users for a lot of money and little effort. Having said this, for pretty much any project, you are going to deal with some of these certification entities anyways (the programming languages used are just a small part of the whole thing). I don't think Rust is cheaper or more expensive than the alternatives for these types of apps. Customer RFPs can ask for anything. If they want it in C++, then that's how it is. Some RFPs actually explicitly ask for Rust nowadays (no C, no C++). But some RFPs ask for FORTH, or assembly, or don't really care at all about the language used. The customer needs to have people trained to "verify" the product that they are getting. If their people only know MISRA C, then that's what they are going to want, and none of this has anything to do with the actual technical pros/cons of any language; it's just a more complex social and engineering thing.
      - pjmlp 5y ago
        I see, thanks.
      - steveklabnik 5y ago
        Thank you for bringing this expertise to this thread. I hope more folks learn about the ways these parts of the industry works.
    - bregma 5y ago
      Part of the safety story for compliance with standards like ISO 61508 and ISO 26262 is that you can demonstrate your toolchain had been validated and verified against something. In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882, and that is usually done through extensive testing with one or more audited and widely-acknowledged conformance test suites. In the case of Rust, that would be "the standard is what the compiler does, so the compiler is by definition 100% conformant." Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. Liability is high when lives are at stake. This stuff is taken very seriously.
  - myrrlyn 5y ago
    (there are none)
tialaramex 5y ago
> We actually also supplied a "fork" of the MISRA C doc, crossing out ~80% of it As an example of what you'd cross out in MISRA I would expect things like the handling of switch. MISRA says thou shalt supply default: cases in a switch. This ensures the switch is exhaustive, but at a terrible price, there are often scenarios in which there are only four possibilities A, B, C, D and MISRA obliges you to add default: and then assert this is never reached because A, B, C, D covers all the options. Rust's match is exhaustive. If you write matches for A, B, C and D, and that compiles, there was no other option. If a library author tells Rust "Today there's A, B, C, D but maybe I need more later" with #[non_exhaustive] your A/B/C/D match doesn't compile, what if, says the compiler, there were more later? If the library author doesn't do that, but then adds E next month anyway, it's a backwards-incompatible change and gets flagged. So in Rust you get the benefit of that particular MISRA requirement built-in, always, and none of the inflexibility because the problem they're worried about was tackled by the programming language as a correctness issue.
- rightbyte 5y ago
  Defensive programming. I think it is fine. But not when it is enforced by rules. The even sillier one is that any 'if-else if' has to have an 'else'.

pjmlp 5y ago

Good it is working for you, although I think it depends how burocratic the customer and government departments might be in each specific project.

volta83 5y ago
There are many levels of certification. This project is in Central Europe. A different team uses it in satellite micro controllers in the US, but I am not involved with that. I don't know of any safety certification process that requires the programming language to have an ISO standard specification.
- pjmlp 5y ago
  Thanks for sharing, I don't mean that they have, more from burocratic point of view, like checklists in RFPs, given conformance with stuff like these https://www.highintegritysystems.com https://www.highintegritysystems.com > Supports IEC 61508, IEC 62304, FDA 510K Hence why imagine Rust might need some kind of good for high integrity computing stamp, be it ISO, ECMA, or something else.
  - volta83 5y ago
    I think what's useful would be to have someone certify the Rust toolchain for some of these. That's what's needed to enable anyone to develop safety critical apps without issues. The problem is that most certification consultancies don't allow you to publish a certification such that everyone can use it. That puts them out of work. The ones that have already certified Rust, make an upfront investment in the certification, and then can certify more users for a lot of money and little effort. Having said this, for pretty much any project, you are going to deal with some of these certification entities anyways (the programming languages used are just a small part of the whole thing). I don't think Rust is cheaper or more expensive than the alternatives for these types of apps. Customer RFPs can ask for anything. If they want it in C++, then that's how it is. Some RFPs actually explicitly ask for Rust nowadays (no C, no C++). But some RFPs ask for FORTH, or assembly, or don't really care at all about the language used. The customer needs to have people trained to "verify" the product that they are getting. If their people only know MISRA C, then that's what they are going to want, and none of this has anything to do with the actual technical pros/cons of any language; it's just a more complex social and engineering thing.
    - pjmlp 5y ago
      I see, thanks.
    - steveklabnik 5y ago
      Thank you for bringing this expertise to this thread. I hope more folks learn about the ways these parts of the industry works.
  - bregma 5y ago
    Part of the safety story for compliance with standards like ISO 61508 and ISO 26262 is that you can demonstrate your toolchain had been validated and verified against something. In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882, and that is usually done through extensive testing with one or more audited and widely-acknowledged conformance test suites. In the case of Rust, that would be "the standard is what the compiler does, so the compiler is by definition 100% conformant." Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. Liability is high when lives are at stake. This stuff is taken very seriously.
- myrrlyn 5y ago
  (there are none)

tialaramex 5y ago

> We actually also supplied a "fork" of the MISRA C doc, crossing out ~80% of it As an example of what you'd cross out in MISRA I would expect things like the handling of switch. MISRA says thou shalt supply default: cases in a switch. This ensures the switch is exhaustive, but at a terrible price, there are often scenarios in which there are only four possibilities A, B, C, D and MISRA obliges you to add default: and then assert this is never reached because A, B, C, D covers all the options. Rust's match is exhaustive. If you write matches for A, B, C and D, and that compiles, there was no other option. If a library author tells Rust "Today there's A, B, C, D but maybe I need more later" with #[non_exhaustive] your A/B/C/D match doesn't compile, what if, says the compiler, there were more later? If the library author doesn't do that, but then adds E next month anyway, it's a backwards-incompatible change and gets flagged. So in Rust you get the benefit of that particular MISRA requirement built-in, always, and none of the inflexibility because the problem they're worried about was tackled by the programming language as a correctness issue.

rightbyte 5y ago
Defensive programming. I think it is fine. But not when it is enforced by rules. The even sillier one is that any 'if-else if' has to have an 'else'.