The language's direct effect on fault tolerance is not always easily measurable. Even in C you could add compile-time instrumentation to discard invalid writes and redirect invalid reads to fixed-size buffers (failure-oblivious computing) and that's just a proactive measure. Recursive restartability, microrebooting, state transfer to stable storage, event logs for fault recovery and piecewise determinism via replay of non-deterministic events, and many other hosts of options are all language-agnostic. Of course, many mission-critical projects will mandate redundancy through n-version programming where you have say a C implementation and Ada implementation of the same spec running concurrently with some failover scheme. Point is most of it is architectural and interface-related, not necessarily language-related. Hell, L4 was written in ASM at first.
Since we can't get that, but instead mostly rely on cargo culting like "Haskell is magic pixie dust because math" for our software safety and availability, I find the prospects of careful HA research (which is more mathematically rigorous) to be daunting.
Software MILS and separation kernels are promising, particularly what Muen does with the Intel VT-x extensions and its rather abundant configuration tools. Getting that deployed is going to be an uphill battle given fault tolerance's neglect, but also because many might perceive the static resource allocation to be anathema to "high scalability".
I think you overestimate public resistance to surveillance. The Church Committee came and went quickly, and was forgotten and dismissed over the legislative band-aids that people blindly believed were as effective as that. Total Information Awareness too got restructured before anyone even blinked. COINTELPRO was not widely protested. DCSNet and FBI snarfing even less so.