Well, that may be true, but what advantages does Ada offer over C++?

http://extranet.eu.adacore.com/articles/Ada%20Cpp.pdf

I had a longer section here, but then came across this. Check out the
section on the type system to get a clearer version of what I wanted
to post. I really think that the type system alone is (for a lot of
the embedded systems I've seen/worked on) a good enough reason to
switch. The rest of the language is simple enough to learn in an
afternoon if you're just wanting to replace C. I don't know how many
bugs I've seen that were caused by everything being an int. Even using
typedefs in C, they don't restrict the range of values or give
significant compile/runtime guarantees when one type is stored into
another and they both happen to be ints or chars or something.

I understand it may be one of the (very few) workable alternatives
for this kind of systems, but I can imagine has many disadvantages
over C++. Where do you find enough developers with Ada expertise,
for example?

Perhaps the greatest problem for Ada, I don't know. There are some
colleges that use Ada in introductory courses. There are others with
strong ties to the defense/aerospace industry that happen to offer Ada
courses as electives. The rest is going to be recruiting from curious
individuals or companies that happened to recognize its value or that
got stuck with a substantial Ada codebase from the 80s/90s.

How current (up-to-date) are Ada toolchains?

How many commercial vendors can provide and support Ada toolchains?

Very, it's an actively developed language. Ada 2012 [1] is the most
recent version, though given that I'm really encouraging this for
embedded use you'd be using a subset of that. AdaCore is the primary
developers of GNAT, which is current through Ada 2012. Green Hills and
Wind River also support through Ada 2012.

Can you expect weird incompatibilities linking between internally
developed Ada code, and externally provided C++ code?

Not sure, FFI is not something that would've been used in any of the
embedded systems I'd have recommended using Ada for. The language
reference does specify how calling to C/C++, Fortran and Cobol code
should function or be exposed within an Ada implementation. See the
above PDF, it speaks a bit about FFI with C.

[1] http://www.ada-auth.org/standards/ada12.html

-----------------

A couple years ago I could've probably written up a better response, I've all but given up on Ada in my workplace.

-----------------

EDIT: I should probably also confess a bit of an infatuation with good type systems and formal verification tools/processes. I've seen what results when these are absent, I've quit jobs because these were absent and the culture prevented any improvements. I'm not working on safety critical systems anymore, but if I ever end up back in those projects I will insist on using the right tools/processes.

I don't want to wake up one day, turn on the news and read about a crash or malfunction that was caused or should have been prevented by my systems. Poor processes and tools enable these failures, and we should have zero tolerance for them. We have certifications/licensing for engineers (mechanical, civil, aerospace, electrical, etc.). If they sign off on a system/design that fails catastrophically and the failure should have been detected (via models or industry standards or whatever), they are held liable. Software developers in the safety/critical systems space have too cavalier an attitude, we're too well insulated from the aftermath of our defects. That attitude may never be changed, but a change in tools/processes to ones that contain, minimize or eliminate large classes of failures is certainly worth the effort.