C++ for game/engine code, C# for tools.
I've also seen some pretty fancy build process stuff done in Perl and makefiles. Perl makes no sense to me. I'm decent with Make, but not expert.
Personally I like C and assembly for game code and C++ for tools... but I mostly do SNES style games.
I love the blood red "language war" tag on this thread 
Write in C - because it is just so awesome and simple. Also there are other reasons that Torvalds would tell you - here is a link for fun - http://harmful.cat-v.org/software/c++/linus
I personally hate virtual machines and interpreted languages, so for me - everything that is not interpreted is fine.
Linus does kernel development, not game development. His choice of C over C++ for a kernel actually makes sense. But sure, that email was on the Git mailing list and was about rewriting Git in C++, but remember that when Linus talks about trying C++ in 1992, C++ hadn't even been formally standardized (and wasn't for another 6 years after that). A good amount of his whining has to do with a) old/pre-standardized C++, b) kernel development (not game development, which typically uses a lot of scripting, actually), and c) the fact that he's prejudiced (honestly, he is).Write in C - because it is just so awesome and simple. Also there are other reasons that Torvalds would tell you - here is a link for fun - http://harmful.cat-v.org/software/c++/linus
I love the blood red "language war" tag on this thread
Yes, it has seen a revival lately.. very appropriate.
There are of course many who keep telling everybody at games development conferences that the future of games is going to be JavaScript and HTML5.
For casual web/mobile games that is very likely to be true in the near future (possibly with some native ties to the platforms marketplace for in-game purchases in cases where the platform lacks a JS accessible API for it), the ease of deployment across the primary platforms for such games (facebook, various webgame portals and mobile phones/tablets) is a huge advantage.
for big AAA titles its unlikely to ever become popular.
I'm extremely biased here because I've been a Flash developer for many years, but I would recommend ActionScript/Flash for a number of reasons:
1. Portability: Between Flash and AIR, your code can reach just about any device and any OS. If you're careful how you code things, the same code can run as-is in both Flash (web) and AIR (desktop/mobile/tablet).
2. Penetration: AIR and Flash combined are installed on some 1.5 billion devices (http://www.adobe.com/ca/products/flashruntimes/statistics.html). Only Java (in the runtime category) comes close to that level of penetration. Practically, this means anywhere Flash or AIR run, your game will run. This includes limited BlackBerry support and, increasingly, smart TVs too.
3. Ease of use / power: I'm not going to pretend that ActionScript code can run at native (C++) speeds, but the runtimes have been greatly improved and run impressively fast. You get access to all of the older Flash APIs as well as extended AIR APIs which, collected, is not easy to stick together into one native game package if you're slapping together disparate libraries. Plus, you're guaranteed that your code will run the same way no matter which device or OS you're running on.
4. History: Adobe has been evolving Flash for many years now. It's a solid product and with AIR, exactly the same skills/language/tools are used to produce apps that run with native privileges. Adobe has built in many great features including direct GPU integration, networking and P2P abilities, fantastic audio support, top-notch video support, and many other features you'll be glad are there once you start building your game.
5. Control: Along with the improvements mentioned above, Adobe has done a lot to "open" up the Flash/AIR virtual machines. This means access to a lot more low-level data which previously would be handled in the background by the runtime. A simple example of this is the sound API which previously could be used to control loaded audio, but the audio data itself remained hidden in memory and protected by the runtime. That data has been opened up as of a few versions ago, opening up raw audio data for applications such as realtime sound effects, software-based audio synthesis, and other useful functionality.
That being said, I would stay away from using Flex / FlashBuilder for producing your game. Great products for coding, but for visual design the old Flash IDE is best. If you're on a budget, FlashDevelop is a great IDE that easily competes with Adobe's commercial products.
At the end of the day, ActionScript is the language that powers both Flash and AIR, and it's also closely related to JavaScript and Java so it's a great "gateway" language too. If top-notch performance is a concern, Flash and AIR may not be the best solution (there's a reason it's called ActionSCRIPT), but you can produce impressive games without the hassle of lower-level languages like C++.
My highly biased two cents ;)
Flash seem to have a very good quality and is interesting -
I never used it. But the two question comes to my mind, could
you ansewr :
- is there some free environment where you can make games and not pay for it? Is there some lightweight environment to build flash programs (how many megabytes to download?)
- what with right mouse button click?, when i play flash games
(recently played one whole day) It is always strange feeling
of not being able to use right mouse button
FlashDevelop is a free Flash/AIR IDE that I use regularly: http://flashdevelop.org/
Apache Flex is another free Flash/AIR IDE based on Eclipse and given royal approval by Adobe: http://flex.apache.org/
These are pretty much complete solutions with the exception of the graphics/motion editor built into the standard Flash IDE. When I was first learning Flash and OOP, I found it extremely useful to have the graphical editor -- it visually represented the code structure behind it. However, anything you can do in the Flash IDE can be replicated using ActionScript so it's not absolutely necessary.
I've known a couple of associates strung out over Java.
However, I myself when offered the choice between C, C++, and C#, chose C++. . . and so that's where my loyalties lie.
To me as an independant learner, it was the easiest among those three to understand.
I'd say that your goals are the most important thing in choosing a language. Are you trying to get a job in the game industry? Or just make a small game for fun? Or are you looking to make money? Is the game going to be 2D or 3D? If your goal is to land a job at a AAA studio doing game or engine development, then you HAVE TO learn C++. If you just want to make a game for fun or to make money, pick a higher level language, like C#, Java, or Objective-C. Performance is only going to matter if you have a very CPU intensive game (such as a first person shooter or any other game with lots of physics calculations). Most of the work these days in games is done on the GPU, which is irrelevent of language. If you are making a 2D game, these factors are even less relevent, and you can basically choose any language you want which has a high level 2D graphics library.
Best of luck.
C++ has widespread penetration in the game dev market, but it's also a piece-of-shit nightmare.
Anyone who describes C++ as a "piece-of-shit nightmare" clearly hasn't used C++11. C++11 is a great language with speed that can only be surpassed by assembly, and freedom and expressiveness on par with Scala.
