You're going to get a pretty broad range of answers with this kind of question, but I'll throw in my two cents. I'm not going to answer your question about the "next big thing" in programming languages, because that's just an opinion survey. Instead, I'm going to describe to you the characteristics of a few popular (and mature and well-supported/documented) languages, so you can pick one for your needs. All of these languages have been around for at least 10 years, so it shows that they have stood the test of time. Let's break down a quant's programming needs into different segments: research, and production.
When conducting research (eg, backtesting a strategy) many people (myself included) prefer to use a high-level interpreted language in order to reduce the number of lines of code between an idea and test results. This is because, although these languages are often much slower than their compiled counterparts, programmer time is much more valuable than execution time at this stage of the game. It is worth bearing in mind, however, that a lot of research is going into making these languages faster, because they're so easy to use! These languages allow you to make small changes, fix bugs, and visualize results in far fewer lines of code than languages like C/C++/Java. They are almost always supported by (and bundled with) a wide variety of domain-specific libraries that extend the functionality of the language.
Some of the most popular research languages are Matlab, Python (with numpy), and R. Someone who has never programmed in their lives can pick up the basics of these languages and write some simple code in less than a day. A free alternative to Matlab is Octave, if you don't want to shell out for the commercial package. If you choose Octave, though, you should be aware that it is just about the slowest scientific computing language available. One language to keep an eye on in the future is a language called Julia. This is an interpreted (ish) language that is designed in such a way as to achieve C-like performance on a wide variety of numerical computing tasks. (There are lots of good papers out there if you're curious about how they do it.) It's a very young language that is rapidly changing (and breaking backward-compatibility), so it might be best to wait for it to mature a bit more before investing time/resources learning it.
For production code, you choose a language based on the demands of your application. If you're trying to do HFT and run it from an interpreted language, you're gonna have a bad time. Interpreted languages are simply not fast enough (yet!) to compete with compiled languages. If you're looking for pure performance, you're not going to beat C or C++ (Fortran excluded from this discussion because I'm really not a fan, and would never encourage anyone to use it). These languages afford the programmer very fine-grained control over every aspect of the program execution, but if you don't want the control, you have to deal with it anyway. If you're not writing assembly, C is about as "close to the metal" as you can get.
The first step backward from the C/C++ family will bring you to Java and C#. The big feature that you'll notice here is "Garbage Collection." If you don't know what this is, don't worry about the details, but it saves you from having to manage your program's memory consumption manually. Since the no-free-lunch idea should be familiar to readers of this site, you might guess that this incurs a performance cost, which can be crippling if you rely on a real-time system. The garbage collector feels a bit like a hiccup in the middle of an otherwise smooth execution. In most applications, you aren't going to notice it. There's a reason that fighter-jet avionics aren't written in Java, and this is it. If you feel that your system needs the same level of real-time control as an airplane, don't pick Garbage Collected languages.
From here, you start getting away from languages that people currently seem to use for quantitative programming. I will make a case for one last one that is very important, if not for model execution. Bash/shell scripts. If you're on a *nix system, you absolutely need to be familiar with these to automate system maintenance tasks.