One of the most fundamental problems in building applications is deciding the technologies with which to construct it. The choices made here are going to affect everything you subsequently do. There are no right answers here (despite the ravings of various partisans). It's possible top build an application successfully on any number of technologies and this is good because it inspires competition and innovation.
 
There are of course a number of wrong technologies. What these are will depend on your problem space. Assembler may be a completely suitable (sometimes the only) choice for an embedded system. But it's entirely inappropriate for the construction of an enterprise application. And anyone proposing a new system built in COBOL should be shot, preferrably out of a canon.
 
So how to make the decision? There are a number of points to consider:
  • What are the preferrences of the client? Trying to sell a Java only client on a Ruby on Rails application may be more trouble than it's worth.
  •  What does the technology offer that's relevant to your problem? I've seen people look at a problem and ask how it can be fitted to their pet technology more than I'd like. Ask if the technology being proposed really matches the problem to be solved.
  • What is the skillbase for the technology? If you can't find anyone who can work with it then all it's other alleged benefits are irrelevant.
  • Does the technology have a community. Some of the best things for building an application on a platform come not from the vendor but from the community. A strong community is also more likely to be able to help you when you run into issues.
  • Is the client willing to wear the risk of your technology choice? Have you even made them aware of it? Cutting edge technology implies greater risks and not everyone is comfortable with them, regardless of the potential rewards. Professional development requires that you do what is best for the client, not what you find the most entertaining.