Ada and SPARK enter the automotive ISO-26262 market with Nvidia

Ada/SPARK vs C++ in safety‑critical systems

• Debate centers on the F‑35’s move from Ada to C++: some see that as a regression driven by politics/contractors and tooling, not by technical merit.
• Others argue C++ is fine if heavily restricted (MISRA-style) and backed by strong processes; language choice alone cannot fix bad systems engineering or management.
• F‑35’s software problems are cited by some as evidence against C++; others blame organizational issues and talent distribution, not the language.

Tooling, ecosystem, and hiring

• Pro‑C++ side stresses a richer commercial tool ecosystem (IDEs, compilers, analyzers) and larger talent pool.
• Pro‑Ada side counters that Ada has multiple commercial compilers, static analyzers, and that many safety‑critical projects run on Eclipse‑like or niche IDEs anyway.
• Concern is raised that specializing in Ada could be career‑limiting in some markets due to HR keyword filtering; others say embedded/firmware skills transfer well and pay in automotive/aerospace is solid.

Rust and other contenders

• Some expected industry to move toward Rust instead; Rust is already used in some automotive contexts and has ISO‑26262‑qualified tooling (e.g., Ferrocene).
• View in thread: SPARK targets full formal verification and very high assurance (e.g., “artificial heart” type systems), while Rust focuses more on memory safety with less emphasis on proof.
• Opinion that Ada/Rust comparison is often distorted by poor or AI‑generated information.

Ada technical and safety properties

• Advocates highlight: strong typing (including units), built‑in fixed‑point types, range checks, constrained profiles like Ravenscar, and SPARK theorem proving for memory and functional safety.
• Disagreement over whether Ada’s abstractions are “zero‑cost”: proponents say generics and slicing can be compiled as efficiently as C++/Rust; skeptics worry about copies vs views and lack of clear monomorphization guarantees.

Certification, automotive context, and hardware

• ISO‑26262 and DO‑178C discussed as process‑heavy standards; languages and tools are “qualified/certifiable” rather than “making systems safe” by themselves.
• AUTOSAR is portrayed as widely used but bureaucratic and domain‑locked.
• ECC RAM is said to be standard for serious safety‑critical automotive systems; Toyota unintended‑acceleration cases are referenced as motivation for stronger HW/SW safety.