I do somewhat disagree with the "insightful" moderation of your post, but also don't care, because I'm not coming to /. very often. Anyway, I feel the need to make a few corrections, since most of what you write about Ada is misleading:
1. It's written "Ada" not "ADA" (The language is named after the first name of Ada Lovelace)
2. Nobody has ever claimed that Ada is a "magic bullet", especially not people who program in Ada. ;-) Ada has its quirks and many annoying features and if you head to comp.lang.ada and ask the (few) people there whether you should use it for project X, they will give you some fairly honest and reasonable assessment - I've seen the answer "not really" come up whenever that makes sense. (Ada seems to be overkill for traditional end-user GUI applications, for example
3. There is no reason to believe that programming a library in Ada would make it obsolete, as long as a proper interface to C is provided - which is very easy. I readily admit that there are problems with the licensing of the GNAT runtime system, though, as it is GPL or MGPL only.
4. Ada source code is always more readable than C source code, provided that you know both languages equally well, of course.
5. Ada can, of course, create libraries with parameter passing conventions compatible with C and callable from C. (To get all benefits of Ada you need a small runtime system, though.)
6. Programming in Ada does not take more time than programming in C. (Actual measurements have indicated the opposite, but let's not get into such details which are always contestable. Let's just say that both Ada and C are both at the slow side of the range.)
7. Ada and Spark were merely meant as examples, but ones I know well enough to be sure about the example.
8. I'm not claiming that C cannot be used safely, but only after an extensive and expensive validation phase (using automatized tools and code review), and for that reason alone it should never be the #1 choice for safety and security critical applications.
I agree with you that many people who talk about a "safe" language have "managed" languages with automated garbage collection in mind, but that many of these languages are not safe at all, nor is dynamic memory allocation a desirable feature in that context. But 30 years experience or not, your claim that security does not hinge on the choice of language is just not true. The language and its implementation (+compiler test suites and validation) are an important part of the overall security and safety. So are management, validation and testing tools, the skills of the programmers, etc., of course.