My criteria for choosing a programming language and its implementation
Generally speaking, the choice of programming language influences your project's success. If you're writing a massively multi-threaded application with a high need of concurrency and fault-tolerance, you might save a lot of time by using Erlang, a language that has been designed for just that (Amazon's SimpleDB, for example, is implemented in Erlang).
Likewise, if you're writing a computer game, you might consider to not write it in Perl.
The important part is: web sites and web programming are almost as diverse nowadays, as computer games are different from telecommunication network software. You might write a web application that needs to provide a uniform, usable interface that is able to present hundreds of database forms to a user and thus you might want to use Java or C# and technologies like Google Web Toolkit or Eclipse RAP. Similarly, you might want to use Python and Django if you're designing the next big social network site and need really nice templates, because your users care about design more than uniform usability.
It's important that you recognize that you can still achieve everything in every Turing-complete language. For a long time, developers tended to focus on the libraries that were available for a programming language to make a choice, or they just went with the one language they knew best. Today, I'd argue that, while you're certainly more productive in a language you know, with libraries you already know by heart, in the long run it might save you a lot of time, bugfixing and grief to choose a language that already has excellent support for your problem, right from the start, built into the language itself. It's difficult to estimate performance gains in this area, especially if you're starting on a big project with many developers with differing skill-sets.
So choosing the language makes a difference:
- Does it have language-level support for what I'm trying to do?
This is where Erlang can shine for example because TCP/IP messaging between processes is built-in. You don't need a library and care about sockets or try to wrap your program around asynchronous I/O. It's also an area where functional languages can shine if they have great support for concurrent map/reduce algorithms.
- Does the language's implementation support what I'm trying to do?
Today you often get access to different libraries and even better implementations of language features by using another implementation of the same language, for example IronPython on the .NET CLR or Jython. It might also be worthwhile to compare different compilers that might get you support for features like signals and slots.
Now, the criteria that I am using are currently mostly revolving around:
Unicode support: does the language fully support unicode?
This is a surprisingly tricky question, because Java supports all of Unicode but can't count chars, Python will change its Unicode support (for the better) in Python 3.0, but it will be an incompatible change, PHP's Unicode support just sucks and Ruby doesn't have any either.
But here's the thing: if your website has any reach at all, you can count on people sending characters over the wire that you don't expect. Not only that: not understanding unicode together with bad programming practices can open you to all kinds of weird "looked ok in binary, but it's a XSS attack"-moments.
Full 64-bit support
Let's face it, 64-bit systems will be normal soon and on the server side that will happen sooner than later.
Predictability
A programming language, especially dynamically typed scripting languages, need a well thought-out type system. Everything else leads to hard to find bugs and unpredictable behavior.
Concurrency
Multi-core is the norm. A programming language must be able to allow me to capitalize on that.
...but that might not fit your needs exactly. It's important however that you know that there are differences. Quite a bit of my daily work consists of finding the best technology to solve a certain problem, or fixing the problems of somebody who made a bad decision some time ago. You can avoid a lot of mistakes by doing just a little extra out-of-the-box internet research before starting a project.

