[ talking about C# ... ]
First, it's a proprietary language, designed for a proprietary
platform (that is, Microsoft's .NET). That's generally a bad
thing, because you're dependant on one single instance which
has total control. That's also one of the points I don't like
Java.
Actually, C# and the CLI are arguably even more standardized than C++.
Like C++, each has an ISO standard, but unlike C++ each also has an
ECMA standard (that is essentially identical to the ISO standard). From
a practical viewpoint, simply having the same standard endorsed by more
standards bodies means little. OTOH, ECMA standards are all available
for free download, which is kind of nice.
Java is a whole different kettle of fish: AFAIK, it's never been
endorsed by even a single standards organization, and it looks like Sun
has given up on even trying to create the illusion of it being
independently defined.
Second, C#, like Java, is working on an abstract machine, namely
the .NET runtime. It is half interpreted, half compiled to some
sort of intermediate language (MSIL). So you have the overhead
of an additional abstraction from the hardware and system
software and the additional overhead of translating the mnemonics
of the abstract machine to commands your system understands
at *runtime*. In other words, it's (generally) slower than a
binary program produced by your highly optimized C++ compiler.
This is an accurate description of the first generation of Java Virtual
Machines, but not really of most current ones, nor of (at least MS's
implementation of) the CLI. These implementations use JIT compilation,
so anything that runs often enough to care much about will get compiled
to native code rather than being interpreted. This doesn't guarantee
the same speed as C++ (any more than code from all C++ compilers is
identical in speed) but using a virtual machine, by itself, doesn't
necessarily imply a loss of speed either. OTOH, even with JIT
compilation, you see the time taken to compile the code as part of the
run-time, which can limit the utility of heavy-duty optimization except
where code is really executed a lot. At the same time, JIT compilation
more or less implies the availability of run-time directed
optimization, which many C and C++ compilers lack. From what I've seen,
the speed handicap of Java stems primarily from other points. I've done
only minimal work with C#, but at least at first glance, its speed
appears to be reasonably competitive as well.
Third, regardless how more abstract and intuitive programming
languages will become, there are always situations where you
need languages which allow to work close to the hardware, like
C and C++. There are situations, where you HAVE to deal with
your memory directly and don't want the garbage collector to
do the work for you.
It's true that access to the hardware is sometimes needed. If you're
really planning on writing an OS (or even a device driver), C# is
probably a poor choice. OTOH, the majority of C and C++ I've seen
really has little need for direct access to the hardware. For even more
direct access to the hardware, you might want to learn Verilog (or
VHDL).
Finally, I'd note that in some cases, interpretation can actually
improve speed. A byte-code interpreter is usually a small, tight loop
with extremely high locality of reference. Byte codes are typically
much more compact than binary code. These two factors tend to lead to
excellent cache usage. A modern CPU can execute quite a few
instructions in the time taken for one main memory access, so
interpretation doesn't necessarily imply a speed loss.
