I left a startup last year (poker company). I was a founding member. We chose to go with c++ for the backend architecture and custom client. My choice was pytho

I left a startup last year (poker company). I was a founding member. We chose to go with c++ for the backend architecture and custom client. My choice was python but I was overruled. It took a LONG time to develop a C++ server, the client was more simple. Security in c++ is hard, memory leaks are hard, crashing on high load is hard to debug. What I learnt from this was... servers are hard and takes a long time to debug. Going with python/perl/C# would have saved us time on memory leaks and some of the crashing (no buffer overruns etc). The downside would be that the server may be slower. BUT the cost to develop the C++ server was about the cost of 40 servers so we could have written a slower app that scaled and bought more servers and rackspace. I estimate choosing c++ added about 6-8 months to the task. Even as I left, while relatively stable the code is brittle and there is only one engineer left who knws the code and he is too chicken to change anything. Launch pressures meant there was 'not time' for unit tests (plenty of time to dig a large hole though) Think hard about your requirements. Most severs spend most of their time waiting. Either the filesystem, database or on high load reading from memory/swap. So the CPU is often under utilised. Interpreted languages while slower can give a similar performance profile to c/c++ but with more cpu utilisation. When you have a LOT of sockets open you can spend a lot of time waiting for the kernel to poke you (even with kqueue or io completion ports). Either way, don't write the underlying server code yourself there are frameworks in ALL languages that will get you 90% of the way. Remember scalability is a 'nice' problem to have as it means you have customers. Concentrate more on scaling across more machines as they are a LOT cheaper then engineering times. good luck