Originally I was very much in favour of finding the 'One language to rule them all'. Being able to do everything with a single language seemed like a no-brainer. But what all these years of try-outs have taught me is that such a language simply does not exist. And I will go one step further to state that they shouldn't exist.
The problem with every single language which tries to be good at everything, is that it inevitably ends up being mediocre at best and a major clusterf*ck at worst (I am looking at you, c++). Yes, it may be able to solve every problem out there, but not at significant cost to the programmer and development cycle. Inordinate amounts of complexity make the whole business of writing a useful application nothing short of a nightmare. A nightmare that you just do not have to put up with.
Lately I have come to realize that the quest for that one language has been a monumental waste of time. I have since settled on a DSL strategy. Pick a problem and then find a language/toolset that is uniquely suited to solve that problem in the most efficient way possible. Not only does this make the development cycle less painful, it teaches you a great deal about the problem domain your are facing, without having to deal with all the superfluous nonsense that a general-purpose language would impose upon you.
By adhering to this strategy, the obvious side effect is that there is no such thing as a favourite programming language. It all depends on what you are trying to accomplish. For the time being, my focus lies on Go. Not because I think it's the best thing that ever happened to the world, but because it solves /my problems/ elegantly and (almost) painlessly. This doesn't mean I will be using it for everything though. I would not even consider using it for something UX/UI related. For the simple reason that it is definitely not the ideal tool for this job. Just like I won't consider using Javascript to build servers and other distributed systems.
Use the right tool for the right job.
Edit: When it comes to DSLs, I would even add this: If you can't find a suitable toolset/language for your problem, consider creating your own.