Develop Reference

XNA 3.1 vs. SDL

I've tried out both and although XNA 3.1 attracts me more because of the ease of being able to just spew code out and not having to worry about memory and garbage clean up and all the nitty gritty crap. You get to write the fun part of the code (if thats even existant :D). However XNA restricts me because I cannot port anything I write with it to Linux or Mac OSX, and even then it makes people who want to play my games have to download .NET 3.5 Redistributable and XNA 3.1 Redistributable which should just not happen. I should be able to just have some DLLs in there as opposed to making my gamers go online and download stuff. Even then there is still the fact that the code will become an absolute mess over time because of the whole "one file for your game" default policy with XNA.
Which do you think is superior?

Really this is going to depend on your level of experience with C++ and if you really see not being able to port your code as a big problem. As for the memory management stuff...
SDL gets a lot easier when you use some of the new features in the C++0x standard such as shared_ptr and unique_ptr, lambdas etc. Even the things in the SDL that require raw pointers are doable as you just use the .get() function on your smart pointer and your life is much easier.
In short: Good at C++ and if you are really interested in easily porting your game to other Systems then I would go for SDL. If you only really know C# and dabble in C++ and it's not a huge deal to only have your game on Windows and Xbox then definitely go for XNA.

I personally prefer XNA. Regardless of personal bias, Microsoft knows how to make some pretty mean software dev tools. XNA is very seamless, and despite its limitations is a wonderful experience. Although the lack of portability is frustrating, at least you can put it on the xbox :)
What do you mean 'one file for your game' policy? You can create just like any other VS project.

From personal experience, far and away XNA. Being able to - to use your phrase - "just spew code out" and rapidly throw things together is a huge benefit in game development.
Obviously I do not advocate that all code is "spewed" out. But the nice thing about C# and XNA is that they give you the option to be less careful about how you code - which you can then exercise in places where it is appropriate.
With C++ and SDL you are forced to write the vast majority of your code "carefully". (Not to mention the fact that you will get it wrong at some point, and C++ is so much more unforgiving about this.)
Some of the problems you mention ("one file for your game", requring a .NET 3.5 redistributable) are not actually problems with XNA - as discussed by Veered and myself in comments. Also, if you use ClickOnce to distribute your games, then it will handle the necessary download and installation of XNA and the .NET Framework for you.
If you have identified a need to port to Linux and Mac, then I would still advocate using C# (via Mono) as a development language - even if you have to use something other than XNA on those platforms.
And there are a bunch of other nice things about XNA and C# - the considerably faster compile times, the content pipeline, the support/updates from Microsoft, the ease of porting to Xbox 360 and Windows Phone, the library of well-written examples, etc.

My vote is for XNA.
I actually began my game using SDL.NET + C# (which covers the memory management that you described, while staying true to SDL) awhile back to learn C#. So if you do indeed like the perks of .Net you could check into that. However, once I discovered XNA and messed around with a few small test games I decided that porting my work over to XNA would be worth it (as I didn't care for cross platform anyhow).
I do understand what you mean when you say the 'one file approach'. Although as others mentioned, this isn't the actual end result, just the way it is presented to be like 'Hey look how easy everything is, update and draw now you got a little guy walkin around shooting fireballs out of his eyes!' Things in XNA feel much more structured than SDL, more hand holding if you will. XNA is easy to pick up and to get done what needs to get done, letting your good coding practices fall into play along the way.

MonoTouch, the future of MonoTouch and whether I should use it for iPhone apps (instead of objective-C)

I've decided to start writing an iPhone app and coming from a c# background, I thought I'd start developing it with mono.
Though this question may be subjective, I'd love some guidance from you.
Is it safe to develop my app using this technology, or should I buy some books and start learning objective C?
I know Adobe were going to release a feature that allows you to build iPhone apps using Flash CS5, but this didn't last long.
I appreciate your feedback.
Marko

Monotouch is doing a great job of keeping up to date (usually within 24 hours of api updates) so just saying you have no idea about xyz but you know abc is much better than it is a bit silly. Monotouch has some serious advantages over obj c - for instance obj c has only been updated something like twice in the last twenty years!! expect good XML, regex, Http support? Think again. Linq in Obj c? never. Good OS community? Not likely. There's plenty of reasons to use MT, aside from C# being a far superior language. Being able to re-use a good percentage of your code in MonoDroid is one. Though there is word that apple are creating a new language - I'm not holding out too much hope for it. We'll see I guess.
I learned Obj C before getting into MT and the reason I went with MT is that using Obj C is like stepping back into the 90s. It just doesn't have any modern language features and is too far behind the curve. Create your bleeding edge apps with their archaic langauge? Thanks but no thanks.

None of us except people who work very closely with the OS and the App store policy in Apple would know whether it is "safe" to develop apps using this technology. Apple can say no anytime in the future, but we don't know. What we know is that all the compiled code has to be in C, C++, or Obj-C. However there's one catch: In some cases you can run interpreted languages.
If I were you, I'd go with Objective-C. We know that Apple supports it fully, it's been in there for almost 20 years. It's not that hard to learn since you know C#. I came from C++/C and it took me about a month or so to learn half of the frameworks. There are many other frameworks which I didn't learn because they're not applicable in my apps (such as accelerators, GPS, OpenGL ES, etc). You probably can get away with this too.
Once again, there's also another way: build it with HTML5. However that way you'd have to consider what your app'll do when it's opened with Safari desktop, Firefox, IE, etc.

The iPhone dev agreement is pretty clear that C# is not an accepted technology for developing iPhone apps. Regardless, Monotouch apps have still been accepted to the app store to date without any problems. My suggestion is to keep in touch with the Monotouch forums to see what their stance is on this issue and make your decision based on that. The long term safe bet is to go learn Objective-C.

Recently Apple changed the clause relating to the third party development tools now stating that if you have prior approval you can use them. I haven't seen any official word that Mono will be allowed though.
If you are coming from a c# background I would highly recommend learning Obj-C because it always helps knowing another language and you could pick it up reasonably easily. Have a look at the stanford University iPhone lectures, they were the best resource when I was learning.
Although I haven't personally used C# or Mono, the iOS SDK once you get to know it has some really great work behind it making it both easy and powerful once you get used to it and I would be surprised if Mono took advantage of it all.

I think it's important to learn the language the frameworks for your platform of choice were written in. Then you can understand more why the frameworks are the way they are, and often anticipate behavior or API calls just based on knowing what is typical for the language and framework.
On top of that there is now a ton of support for blocks across the API (iOS4 and on only), which may take some time to be incorporated into MonoTouch. Overlay frameworks are always a step behind the base platform so it's nicer to be using the frameworks directly.

It's now been months since the Flash debacle and Monotouch and Unity are still rocking along.
As developers in a .NET shop we're looking at expanding into iOS development. After prototyping some fairly basic stuff in Objective-C, We're 100% committed to using Monotouch, it's worth every penny.

Quickest (Easiest) GUI MFC or C# or QT or?

I have just finished my first real commercial application written in C++ / MFC.
The application consisted of agent installed on users workstations which in turn was controlled from a GUI Application on an administrators workstation. I choose C++ / MFC for these reasons.
Because I didn't know C#
Because I was not sure how long it would take for me to become as productive in a new lanuage
Because I did not want the hassle of installing the .NET runtime on workstations some of which might be W2K.
Now I am thinking of my second application which will again consist of an agent & a GUI Application. I am happy to continue on the same track with the agent for the reasons above but the GUI application will be much more complicated then the first. The first GUI app took a very long time to develop, was torturous and looked out of date even though it was freshly made.
Should I just bite the bullet with .net c# or look into something like QT.
TIA.

If you want really fast results, use .NET WinForms. Nothing beats the speed of putting together a GUI app and filling it with life, except maybe Delphi. The C# language and the .NET Base Class Library will also give you a huge productivity gain, even over the already great Qt framework. If you stick to the basic Windows Forms controls, it will even run on Mono.
WPF is even more productive once you're used to it, but getting used to it takes way more time than for Windows Forms.

.NET C# is a very good choice for GUI applications more generally. It's simple, to-the-point and there are vast resources on the internet.
The only thing against it I can think of, is platform compatibility, but if you're limiting yourself to C++/MFC, that shouldn't be a concern to you.
Even if you want to go platform-independent some time later, you can make a separate Gtk in .NET on Linux (Mono, the open-source .NET framework). Heck, there's even a Cocoa (Mac OS X) binding, I just don't know how mature it is. Furthermore Windows Forms is largely supported in Mono already... it really surprised me how mature it is when I was trying it out, although my primary experience with C# is on Windows.
For GUI application, you won't regret using C#. Even if you want to go cross-platform, and certainly not if you intend to only target Windows clients.

C# will almost definitely make you more productive!

Delphi. Produces stand-alone Windows executables which will work fine on Win2K (best OS Microsoft ever produced - this post is being written on it). Only disadvantage is Object Pascal, but if you know C++ it's very easy to pick up - and its was designed buy the guy who designed C#. The IDE is several orders of magnitude more productive than MFC with VS.

I've done them all - a monkey can use C#, it's all drag and drop interfacing and public accessors. I wouldn't wish using MFC upon my worst enemy, and QT just wasn't as intuitive as C# for me. It's also really easy to make C# look nice. Difficult things like changing colors and flashing controls are trivial in C#. It also has built in styles to use. I use it professionally daily. The only time I use C++ is if I'm programming a server where every microsecond counts.

The first question would be exactly what caused the difficulty in developing the GUI with MFC. Was it inherent to MFC, or what it because you were learning something new, and didn't really know what you were doing? To put it slightly differently, if you had to do it again today, how would the difficulty compare?
Make no mistake about it -- MFC is an old design with far more than its share of problems, shortcoming and design flaws. .NET is a lot newer, but has far more than its share of problems, shortcoming and design flaws as well.
Along with that, .NET is just plain huge. It's reasonably well organized, which helps, but it still takes quite a while to digest the sheer volume of information necessary to use it well. Likewise, while C# (for the most obvious example) is a perfectly decent language, learning to use it well isn't an overnight task either. This is probably a smaller issue though: C# doesn't really have many new concepts compared to C++. Just for example, a competent C++ programmer can easily read C# almost immediately, and while he may not use it optimally, can also write bits of C# immediately as well.

on which platform will your second app run on?
if it's XP and up i'll suggest C# / WinForms / GDI.

C# isn't that hard to adapt to, and there are literally a ton of examples online, and great books (the Head First one caught my eye as you can code a nethack clone and other fun projects). I've had to transition from C++ to C# myself, and it wasn't that rough at all (in fact it seemed like a pretty easy transition), and allowed me to rapidly prototype.
Good luck!

Windows Mobile is hell for new developers? (If I'm not wrong)

I am new here and new to windows mobile development. But I have seen and experienced, for new developers having no trainers or experienced people around windows mobile development is like a hell shaking one. In complex topics you are going to find help from nowhere except you are lucky.
So my question is how should I gain expertise in windows mobile without having any trainer. The thing that i only know is C# and have a rough experience of one and a half months in windows mobile development

Yea.... it's quite a step to be honest. It's evil as well because at first glance it looks to be so very simple but then it turns around and bites you.
I speak from experience as I made this journey starting in 2003. Oh, I had no trainer either so I just learnt via bitter experience.
Know your limitations
I remember the first ever CF application. I was such an idiot..... I wasn't much good at developing back then either. First mistake I made was overestimating CF 1.0. I couldn't possibly imagine that the CF didn't have a read-write datagrid so I specced it...... then found out that oh yes, there wasn't one. So I had to write one myself (and remember I was rubbish at this time too). I hacked one into the existing datagrid (although tbh I should have just started from scratch). I remember that the "delete" function where I had to remove a row and then select the "now currently selected row" was hellish because it would go up or down depending on how many items were in the collection and where the scrollbar was.
There are many times that my desktop development buddies will categorise me as mad when I tell them what i'm working on.
"You're doing manual Xml Parsing? Are you crazy?"
"Ewwww code gen?"
"You.... re-use your windows forms?"
Yes, working on CF will make you look crazy to outsiders.
Performance
This can be taken to extremes but every little does help. If your building a big flexible application then think very carefully about perf. Consider replacing Reflection with codegen. Consider using an XmlReader instead of an XmlDocument. Sure this advice might be crazy in most cases for desktop but for CF it is sensible.
Know your PInvokes
In desktop land you can live in pure managed. No chance of that happening on CF. Some of the simplest things (playing a sound, setting the time, changing the volume, networking, etc etc) still only exist in the unmanaged world in Mobile. OpenNETCF have done an awesome job in exposing some of these but you will always stumble into one or two where you will need to write your own.
There is true, there is false but there is also FILE-NOT-FOUND
PowerManagement, how I love thee. In a usual C# app code goes the way of the logic (like a fork with an IF), perhaps an exception will be thrown and perhaps there will be many threads treading the path of the code. This is already complex. Add into the mix the idea that the power might vanish at any point. That's right, the using statement you were relying on to call Dispose might never call dispose because the device was turned off and then it ran out of power.
Device specific fun
Another big difference in desktop/mobile world is hardware and manufacturers. On the PC you can generally assume that the hardware will be okay and firmware updates should do the job. In CF a firmware update may well kill your code. Some hardware might sorta, kinda work if you bash it round the head in a certain way. Basically your device integration can (worst case) be a big black hole of time. Remember to work this into your estimates.

Learning to write actual maintainable, saleable and usable applications for the Compact Framework is difficult. The CF is way, way scaled down, so there is a lot that a desktop developer will not have that they are used to. I'd been developing CF applications since before the CF existed and I still find many things difficult (just try getting a control with transparency drawn into a container on a form with a background image and doing it without looking at the code in Project Resistance).
In my opinion, there really are 2 things that are essential.
You must be able to read and understand C/C++. All of the SDK docs are in C and a large amount of samples for using anything useful on the device tend to be in native code. If you can't translate that, you're at a serious disadvantage and you have to hope someone else has already done the work. Even if they have, they you have to rely on them having done it right.
You need CF experience. Desktop experience is largely worthless in the CF environment once you get past syntax. Laziness like data binding, using Data Sets, not cleaning up objects and all of those things that desktop developers do every day will kill a CF app. You need to throw out what you think you know and start re-learning. You do that by simply writing code every day.
Don't expect miracles either. I've been writing code for Windows CE for over a decade now and the amount of things I don't know about the platform still far outweighs the things that I do know.

If I understand your question....
If you have c# experience, you will not really need a trainer.
Building on Windows Mobile is very straight forward and easy if you know .net.
If you have Visual Studio (I think any edition apart from express), it is simply a matter of starting a new project and selecting mobile device.
I honestly love it! I build small applications all the time for my phone... little calculators for when I go shopping, programs that fire off a trigger and get a response from a web service and more... basically to make my phone do what I want (and no one else would be interested in).
I go by the method of simply writing an application the way I want and then if a feature is not supported by the cut down .net compact framework, I try and search for an alternative method that is - however, I have found little that doesn't work.

Developing in the CF can be challenging. Knowing C# is important before moving forward with the Compact Framework - to which you have. I would suggest that you start with smaller applications. Once you get the feel of Visual Studio and working with the emulator, I would suggest that you play around with a setup project. Once you get an idea on the flow of CF development, deployment will probably be your next step.
One area that I find that I spend time on is Designer support. If you are writing controls for other developers - design time support is crucial. Checkout the article at http://www.mooseworkssoftware.com/VS2005%20Control.htm for more information (I know its for VS2005, but it really helped our development).
As you move forward, create small projects in different areas and learn the pitfalls to each. An example would be GUI and dealing with different screen resolutions that are supported by different devices. Next, maybe DB support. After you get comfortable with a couple of areas, bring them together in a project and build from there.
Give it time - sometimes it will be painful, but the possiblities are endless in writing applications for the CF and what the market is calling for.
Craig

To answer your question, Windows Mobile is like paradise for new developers. You use the same tools and languages you are used to from the desktop world and essential things like in device debugging and emulators are just there for you. You can build simple applications with no training, just by following one of the many beginners tutorials available.
After that, there are of course many complicated and difficult issues to overcome, but in my opinion the fact that you will be able to start quickly is very important.
Also, you need to also need to compare Windows Mobile with other mobile platforms. Compared to platforms like Symbian, Brew and J2ME Windows Mobile is much more advantageous for new developers. I don't have experience with iPhone and can't comment about it, but comparing to everything else, Windows Mobile is easier.

Good language to develop a game server in?

I was just wondering what language would be a good choice for developing a game server to support a large (thousands) number of users? I dabbled in python, but realized that it would just be too much trouble since it doesn't spawn threads across cores (meaning an 8 core server=1 core server). I also didn't really like the language (that "self" stuff grossed me out).
I know that C++ is the language for the job in terms of performance, but I hate it. I don't want to deal with its sloppy syntax and I like my hand to be held by managed languages. This brings me to C# and Java, but I am open to other languages. I love the simplicity of .NET, but I was wondering if, speed wise, this would be good for the job. Keep in mind since this will be deployed on a Linux server, it would be running on the Mono framework - not sure if that matters. I know that Java is syntax-wise very similar to .Net, but my experience with it is limited. Are there any frameworks out there for it or anthing to ease in the development?
Please help me and my picky self arrive on a solution.
UPDATE: I didn't mean to sound so picky, and I really don't think I was. The only language I really excluded was C++, Python I don't like because of the scalability problem. I know that there are ways of communicating between processes, but if I have an 8 core server, why should I need to make 8 processes? Is there a more elegant solution?

I hate to say it, and I know I'm risking a down mod here, but it doesn't sound like there's a language out there for you. All programming languages have their quirks and programmers simply have to adapt to them. It's completely possible to write a working server in Python without classes (eliminating the "self" variable class references) and likewise just as easy to write C++ with clean syntax.
If you're looking to deploy cross-platform and want to develop cross-platform as well, your best bet would probably be Java. It shorter development cycles than compiled languages like C and C++, but is higher performance (arguable, but I've always been anti-Java =P) than interpreted languages like Python and Perl and you don't have to work with unofficial implementations like Mono that may from time to time not support all of a language's features.

I might be going slightly off-topic here, but the topic interests me as I have (hobby-wise) worked on quite a few game servers (MMORPG servers) - on others' code as well as mine. There is literature out there that will be of interest to you, drop me a note if you want some references.
One thing that strikes me in your question is the want to serve a thousand users off a multithreaded application. From my humble experience, that does not work too well. :-)
When you serve thousands of users you want a design that is as modular as possible, because one of your primary goals will be to keep the service as a whole up and running. Game servers tend to be rather complex, so there will be quite a few show-stopping bugs. Don't make your life miserable with a single point of failure (one application!).
Instead, try to build multiple processes that can run on a multitude of hosts. My humble suggestion is the following:
Make them independent, so a failing process will be irrelevant to the service.
Make them small, so that the different parts of the service and how they interact are easy to grasp.
Don't let users communicate with the gamelogic OR DB directly. Write a proxy - network stacks can and will show odd behaviour on different architectures when you have a multitude of users. Also make sure that you can later "clean"/filter what the proxies forward.
Have a process that will only monitor other processes to see if they are still working properly, with the ability to restart parts.
Make them distributable. Coordinate processes via TCP from the start or you will run into scalability problems.
If you have large landscapes, consider means to dynamically divide load by dividing servers by geography. Don't have every backend process hold all the data in memory.
I have ported a few such engines written in C++ and C# for hosts operating on Linux, FreeBSD and also Solaris (on an old UltraSparc IIi - yes, mono still runs there :). From my experience, C# is well fast enough, considering on what ancient hardware it operates on that sparc machine.
The industry (as far as I know) tends to use a lot of C++ for the serving work and embeds scripting languages for the actual game logic. Ah, written too much already - way cool topic.

Erlang is a language which is designed around concurrency and distribution over several servers, which is perfect for server software. Some links about Erlang and game-servers:
http://www.devmaster.net/articles/mmo-scalable-server/
http://www.erlang-consulting.com/euc2005/mmog/mmog_in_erlang.htm
I'm thinking of writing a game-server in Erlang myself.

Speaking of pure performance, if you can run Java 6 you get about 1:1 performance when compared to optimized C++ (special cases notwithstanding, sometimes Java is faster, sometimes C++), the only problem you will have is of course stuff like database libraries, interconnectivity, scalability and such. I believe there's a variety of good to great solutions available to each of these problems but you won't find one language which would solve everything for you so I have to give you the age old advice: Choose the language you like and use that one.
Oh, you're still reading this? :) Well, here's some extra pointers.
EVE Online uses Python for its client and server side code and it's both bug-ridden and laggy as something I don't think I should write here so that'd be an example of how Python can be extended to (poorly) serve vast amounts of users.
While Java has some good to great solutions to various related problems, it's really not the best language out there for vast amount of users; it doesn't scale well to extremes without tuning. However there's multi-VM solutions to this which somewhat fix the issue, for example Terracotta is said to do the job well.
While C++ is rather cumbersome, it allows for such a low-level interaction with the system that you may actually find yourself doing things you thought you couldn't do. I'm thinking of something like dynamic per-core microclustering of runtime code blocks for "filling" every possible clock cycle of the processor as efficiently as possible for maximum performance and things like that.
Mono is far behind the .NET VM/equivalent on Windows platforms so you wouldn't be able to use the latest and fanciest features of C#. However Windows XP (x64) OEM licenses are so laughably cheap at the moment that with small investment you could get a bunch of those and you could then run your code on the platform it was meant to be. And don't fall into the Linux hype, Linux is your saviour only if you really know how to use it and especially XP is pretty damn fast and stable nowadays.

What kind of performance do you need?
twisted is great for servers that need lots of concurrency, as is erlang. Either supports massive concurrency easily and has facilities for distributed computing.
If you want to span more than one core in a python app, do the same thing you'd do if you wanted to span more than one machine — run more than one process.

More details about this game server might help folks better answer your question. Is this a game server in the sense of something like a Counter Strike dedicated server which sits in the background and hosts multiplayer interactions or are you writing something which will be hosted on an HTTP webserver?
Personally, if it were me, I'd be considering Java or C++. My personal preference and skill set would probably lead me towards C++ because I find Java clumsy to work with on both platforms (moreso on Linux) and don't have the confidence that C# is ready for prime-time in Linux yet.
That said, you also need to have a pretty significant community hammering on said server before performance of your language is going to be so problematic. My advise would be to write it in whatever language you can at the moment and if your game grows to be of sufficient size, invest in a rewrite at that time.

You could as well use Java and compile the code using GCC to a native executable.
That way you don't get the performance hit of the bytecode engine (Yes, I know - Java out of the box is as fast as C++. It must be just me who always measures a factor 5 performance difference). The drawback is that the GCC Java-frontend does not support all of the Java 1.6 language features.
Another choice would be to use your language of choice, get the code working first and then move the performance critical stuff into native code. Nearly all languages support binding to compiled libraries.
That does not solve your "python does not multithread well"-problem, but it gives you more choices.

The obvious candidates are Java and Erlang:
Pro Java:
ease of development
good development environments
stability, good stack traces
well-known (easy to find experienced programmers, lots of libraries, books, ...)
quite fast, mature VM
Pro Erlang:
proven in systems that need >99.9% uptime
ability to have software updates without downtime
scalable (not only multi-core, but also multi-machine)
Contra Erlang:
unfamiliar syntax and programming paradigm
not so well known; hard to get experienced programmers for
VM is not nearly as fast as java
If your game server mainly works as a event dispatcher (with a bit of a database tucked on), Erlang's message-driven paradigm should be a good match.
In this day and age, I would not consider using an unmanaged language (like C or C++); the marginal performance benefits simply aren't worth the hassle.

It may depend a lot on what language your "game logic" (you may know this term as "business logic") is best expressed in. For example, if the game logic is best expressed in Python (or any other particular language) it might be best to just write it in Python and deal with the performance issues the hard way with either multi-threading or clustering. Even though it may cost you a lot of time to get the performance you want out of Python it will be less that the time it will take you to express "player A now casts a level 70 Spell of darkness in the radius of 7 units effecting all units that have spoken with player B and .... " in C++.
Something else to consider is what protocol you will be using to communicate with the clients. If you have a complex binary protocol C++ may be easier (esp. if you already had experience doing it before) while a JSON (or similar) may be easier to parse in Python. Yes, i know C++ and python aren't languages you are limited to (or even considering) but i'm refer to them generally here.
Probably comes down to what language you are the best at. A poorly written program which you hated writing will be worse that one written in a language you know and enjoy, even if the poorly written program was in an arguable more powerful language.

You could also look at jRuby. It comes with lots of the benefits of Java and lots of the benefits of Ruby in one neat package. You'll have access to huge libraries from both languages.

What are your objectives? Not the creation of the game itself, but why are you creating it?
If you're doing it to learn a new language, then pick the one that seems the most interesting to you (i.e., the one you most want to learn).
If it is for any other reason, then the best language will be the one that you already know best and enjoy using most. This will allow you to focus on working out the game logic and getting something up and running so that you can see progress and remain motivated to continue, rather than getting bogged down in details of the language you're using and losing interest.
If your favorite language proves inadequate in some ways (too slow, not expressive enough, whatever), then you can rewrite the problem sections in a more suitable language when issues come up - and you won't know the best language to address the specific problems until you know what the problems end up being. Even if your chosen language proves entirely unsuitable for final production use and the whole thing has to be rewritten, it will give you a working prototype with tested game logic, which will make dealing with the new language far easier.

You could take a look at Stackless Python. It's an alternative Python interpreter that provides greater support for concurrency. Both EVE Online's server and client software use Stackless Python.
Disclaimer: I haven't used Stackless Python extensively myself, so I can't provide any first-hand accounts of its effectiveness.

There is a pretty cool framework in development that addresses all your needs:
Project Darkstar from Sun. So I'd say Java seems to be a good language for game server development :-)

I know facebook uses a combination of Erlang and C++ for their chat engine.
Whatever you decide, if you choose a combination of languages, check out facebook's thrift framework for cross language services deployment. They open sourced it about a year+ back:
http://incubator.apache.org/thrift/

C++ and Java are quite slow compared to C. The language should be a tool but not a crutch.