This is going to be something of a rant, but roll with it.This is a controversial opinion, but I don't believe someone should be a security engineer or a security consultant until they are a provably competent software developer.
This harkens back to the analogy of writing and editing - how can you expect to perform competent source code review from a security perspective without having a deep understanding of programming? Even if you do not know a specific language you're reviewing (ideally you should, though), you can at least generalize your understanding to look for common patterns of insecure coding.
The reason why I stress this so emphatically is because, despite the fact that you are asking which programming languages to learn, my experience with the security industry is that most people just don't have much real programming experience, which is absurd.
There are many firms where they will bill out their consultants at $2000+ per day and their consultants couldn't build a simple Twitter clone if they were handed a complete spec.
I would much rather someone who can sit down and write a compiler and who has no security experience whatsoever than someone who knows all the payloads for XSS and how to find them manually. One of these people understands software engineering as a discipline and where it goes wrong, and the other is basically learning different "routes" without truly understanding everything under the hood. I can teach the person who writes compilers to find serious memory corruption vulnerabilities in a week. I can't teach someone who has never programmed to find subtle mass assignment flaws in Ruby/Rails.
This is not a straw-man dichotomy. Like 'tptacek said, it is absolutely necessary for you to have a programming background if you want to work in AppSec. And God help you if you try to work on security in firmware or embedded systems and don't have this background.
My personal opinion is that all security engineers should be senior software engineers. There is a good quote by Ryan McGeehan (former Director of Security at Facebook, then Coinbase, now Hackerone) where he explains that the most competent security engineers start out by fully mastering a particular discipline. After they hit that point, finding vulnerabilities becomes extremely easy. You don't need to memorize different payloads or routes or rote methods of testing. When you have written a lot of C you will understand a buffer overflow in a half hour (enough to really be dangerous, anyway).
Working in security without a lot of experience programming is like trying to ski a black diamond without having mastered all the fundamentals. Do not do it. It is entirely too fashionable in the industry to hire people who don't know what they're doing, please do not add to this.
Now that my rant is over - you should learn Python and C. Ruby and Lua are also good; most people you'll find in the industry will be doing scripting in Python. You should know C for its rich history and deep connection with the information security industry, and also because most of the interesting vulnerabilities will be found in software projects written in C.
Source: A few years of security consulting, and now working as a security engineer in FinTech.