JVM JIT tends to be the best

Yes... Micro benchmarks are exactly the best way to verify real performance. /s

Banks don't want to leave JVM, they don't care much about Scala or Java....

C/C++ are great when it comes to highly predictable data flows or very small modules. Otherwise it's extreme cost of constant profiling of the code to actually identify the changing patterns that cause slowdowns. That being said, C/C++ can be much more than 2x performance of a JVM.

And what 32 bit integer is not a 32 bit integer in C/C++ or Java?

1: Those bounds checks come at a cost of having overflows getting in the way of actually checking bounds. An overflow of an unsigned value results in just a small number... that means that you still have to check the lower bounds no matter what.
2: They store the same number of values as unsigned, it's just handling of those values and comparison operations differ. A signed and unsigned 32bit integers store 2^32 values.
3: Crypto algorithms do not operate numerically, thus 2147483647 * 100 will yield exactly the same result for uint32 and int32 as much as any crypto algorithm is concerned.
4: Therefore you send 2147483648 in binary form as 4 bytes = 0x80000000

The fact that lack of unsigned integers has not stopped Java shows that the designers made the right choice. If you need to have a value larger than 2bn you will probably not be satisfied with 4bn and will need a larger type. And in general, you rarely need to operate numerically without a sign.

I hope you are kidding here, because that is far from the case. Java is still the de-facto language for most server-side applications. RoR never outgrew it's hipster background. It has been 7 years since RoR had it's hype peak... The hype waned and RoR is still a rarity.

Your assumption of the intention for the default methods is incorrect. They were a result of mixin envy, not adding new default implementations for future proofing.
Java developers tend not to have issues with future proofing for new functions in interfaces.

there are very strict limitations to the implementation. The concrete class hierarchy has the final say. Thus you can't provide default implementations of hashCode, equals and toString.

Well... If you signed up for GMail, then why are you complaining? Google is not hiding their services in any way, if you want it you can sidestep Google.

NSA provides no services. You can't sue NSA and they pretend that it does not even exist!

Actually that information will help greatly in sorting the emails. Some people I'm in contact with routinely send me stupid email and happen to be business associates. I do not want to go through their cupcake bake-off blabber, to see that they have sent me estimates for projects.

In short - Google offers no more information than you can't already gather from other sources, concerning low volume demographics.
Consider that you are targeting a DnD players in Boulder(CO), going through Google is the least efficient tools that you could use to get personal details about your target group.
Targeting any group larger than that is pretty much useless and you can't practically gather any valuable personal information.

Yes... Which are male, single, under 30 interested in cars.
Please note, that private information is only the information that can personally identify you. Unless you happen to live in a country/city that has you are the only person fitting that profile, you have no basis to claim that your private information is sold.