You have to be god-like to not create security vulnerabilities in significantly C/C++ software. 'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere). But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.
Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
Guess what language Java/Python/etc are implemented it.
At least python and ruby are both implemented in a wide variety of other languages, not just C. There's even a very good implementation of python in python. Perhaps surprisingly some of these alternate implementations are even faster than their C-built equivalents. Their main drawback of course is lack of ability to link directly with C code.
With excellence and discipline it surely is possible to create decently secure code in C++. For me it's much harder and slower than ruby or python. Some projects are probably best done in C too, but I don't think bitcoin is one of those.
Except of course if it's the language the main developers are most comfortable with, which most often is the main overruling argument deciding language for any given project.-coinft
