As to Ada... I've coded in Ada too back then, and I know of some big code-bases that are rock solid in Ada. Unfortunately, there is a severe shortage of Ada programmers who are willing to maintain those code-bases, so what happens is that a lot of money is being thrown at converting all that Ada code to C++ code, using semi-automated tools where possible. This auto-generated C++ code is then manually re-validated by C++ hackers (and that's what is so costly), and from here on, it will persist as C++ code, maybe for decades.
That's the way it goes. A language may have merits of its own, but if it is not popular and if you can't get enough people to maintain your sizeable code-bases, that language is ultimately of no use. C++ seems like a good compromise between openness, royalties/patent-lessness, speed, type safety, maintainability (when done right!), and long-term maintainability through coders. Despite its known shortcomings. No Rust, not even Ada can beat that.
Maybe someday someone will figure out how to use C++ in a clean, nice looking style. Then I'll use it. Until then, I'm staying away.
You may also make suggestions and contribute to shape the next iterations of the C++ standard...
Personally, I really like what has become of C++ since C++11, and I'm seeing that C++17 is getting some real nice additions in the Standard Library too. What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon). Missing networking is a big minus IMHO. I also consider the difficulty of writing more specialized streams, e.g. for encryption etc. a small minus... but that may only be me not yet grokking enough the iostreams / streambuf library design to extend it that way.
Save for that, C++11's style and philosophy is something you get used to after a while. It takes some time to finally "get it" and get the hang out of it. That's not just a couple of syntactic rules and keywords and weird ways to write templates and template specializations and throw in iterator flavors everywhere where you don't expect them to come up, it is more than that. Once you finally reach some stage of enlightenment, you'll start to really like C++ and will start coding in it as it was supposed to be and designed to be. I know, it sounds like a pathetic excuse for not being easily accessible...
Knowing some classical math won't really help you with floating point
No, not if you keep using that old 1st gen Pentium CPU in the basement...
Let me put this file I encrypted with PGP on an anonymous FTP site / dropbox. You can then download it and tell me what's in the file. No wait, you can't, because it's encrypted with an OS-agnostic algorithm and you don't have the key.
I'm not sure you get the point. Are the (private) keys located on the Android device? Do you enter the passphrase to unlock the private keys directly on the Android device? If so, your beloved App's security is toast, because key material is hitting the OS before it even reaches the App.
Encryption is out there, and a reality. If the phone manufacturer compromises their full-disk encryption, then app makers start writing un-compromised encryption into their apps.
If it were only so simple! If the underlying OS is compromised and can't be trusted, what's the value of any encryption on top of that?
Let's say Gov't passes an anti-encryption law for smartphones. First thing Apple and Google will (have to) do, is to purge their App Stores from all apps that implement un-snoopable encryption. That's the first step. So no un-compromised encryption in apps for the plebs.
Then, next step, Apple and Google will (have to) remove all encryption libraries and support in the OS (libraries etc.), or cripple them with backdoors, so the Government(s) and other evil-doers can snoop right back in, even if Apps are still allowed to call encryption APIs.
Finally, every I/O in and out of an App has to go through some layer of the OS; and if the OS can't be trusted, what good is solid encryption? You as a user can't listen to encrypted voice, you can't read encrypted messages, you can't watch encrypted photos and videos: you're the analog counterpart that requires decryption, and this is the point where device makers will be compelled by the Gov't to let the snooping start.
Of course, there's still the option of alternative ROMs that you compile yourself out of reliable source code (CyanogenMod et al. come to mind); but here, there are still some binary blobs that are required to drive the modems etc.: same problem as with a regular Linux: do you trust these, if Government were to mandate snooping on a hardware low-level from manufacturers?
The amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond.