Why would download size be a problem to a programming language? If anything, I'd say that's platform's issues. If Windows doesn't ship with VC++ runtime by default, then that's kind of Windows fault. If Windows doesn't ship with a JRE, then that's Windows fault, which is obvious since they are promoting .NET.

If I write an application for Mac OS X, whether that be in Java or C++, I'd use the most compatible libraries for Mac OS X, right?
If I develop for Android, hey use Java, unless I want to go deeper to the native, then I'd use C++.

C is best if you're going for speed.

C++ has many of the same slowdowns as Java does now. In fact today Java7 is about as fast as C++.

Java is in limbo in terms of support. The buyout of Sun by Oracle resulted in several years of Java 6 and left Java 7's updates out in the cold. Nothing like having to wait 5 years for a JSR updates that were ready to go to be integrated in. If Java 8 is released on time then that drawback is over, but if I have to wait 5 years again I will be upset.

Java tends to have outdated API's that people insist on trying to use in games, and API's that weren't tailored for games. For example Key Listeners that were intended for Swing Gui's don't work well in games. Java Sound has been neglected for years, and because of legal issues the JMF was abandoned along with MP3 support.

You'll need to get a real game api for java like lwjgl. Otherwise you're asking Java to do things in a way it wasn't designed for.

C and C++ is easier to port to consoles. XBox, Wii and PS3 do not have a real JVM supported for games. The PS3 has a slimmed down JVM for Blue-Ray functionality only.

If Windows doesn't ship with VC++ runtime by default, then that's kind of Windows fault.
...
then that's Windows fault, which is obvious since they are promoting .NET.

A related topic was once discussed regarding steam installs, where each game installs its own DX and runtime.

In short, each application will almost certainly install VC or DX runtime due to licensing reasons. Microsoft forbids distribution of certain files in any form, except for the one provided by them.

So even on Windows, when using DX, your application will need to deliver stock MS installer for DX and VC redist. One cannot, for example, modify the installer to download only the missing dlls. Same for .Net.

For DX or .Net, it's even more important since legacy versions (ones required, tested or supported by a release) might no longer be easily available for end user download.

Silly, but that's the way it is.

If Windows doesn't ship with a JRE, then that's Windows fault, which is obvious since they are promoting .NET.

No Microsoft is forbidden from bundling a Java Virtual Machine with Windows due to being caught being evil. http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine

[quote name='alnite' timestamp='1327441512' post='4905894']
If Windows doesn't ship with a JRE, then that's Windows fault, which is obvious since they are promoting .NET.

No Microsoft is forbidden from bundling a Java Virtual Machine with Windows due to being caught being evil. http://en.wikipedia....Virtual_Machine
[/quote]
Interesting, especially the embrace, extend, extinguish strategy.

Is there any anti-trust law that's preventing Microsoft from installing the same JRE that's provided by Sun/Oracle (rather than creating their own)?

[quote name='medv4380' timestamp='1327443572' post='4905906']
C is best if you're going for speed.
C++ has many of the same slowdowns as Java does now. In fact today Java7 is about as fast as C++.

Uh,[color=#0000ff] [sup][citation needed][/sup]
I'd like to see a benchmark proving this, where it wasn't simply because someone had written crappy C++ code.
You should be able to get the same assembly out of a C and C++ solution to a problem...
[/quote]

Here: http://shootout.alioth.debian.org/

If you don't like the crappy C++ code of any of the implementations, I think there are ways for you to submit a better one. But C and C++ are pretty much the same in that comparison.