Language Importance for DevOps Engineers
blog.hypergeometric.com
blog.hypergeometric.com
Shell scripts: a little bit here and there. Mostly for my own shortcuts to save time doing repetitive stuff.
Perl, PHP, Ruby, Chef/Puppet, Haskell: Zero.
Javascript: Only if cargo-culting a "make this table sortable" thing into a web page counts.
Java: Just that one time, to help out some folks who were on vacation when their service broke.
SQL: Unfortunately, more than I like to admit. Almost always used in conjunction with...
Python: Far more than I liked. One service was nothing but Python code written with a typical scripter mentality. Pain.
C: Rarely, like a one-afternoon tool we used just once.
C++: Constantly. So many things were and are written in it.
I must say that lumping C and C++ together is worrisome. Odds are, you're not going to use them the same way.
I'd pick ruby over python, but thats just me. I'd still choose perl over either, but thats because things like threading and the low memory footprint are appealing.
DevOps is about running the stack. If you don't understand the stack your, you're not doing devops.
DevOps is about continuous deployment, continuous integration, automation, infrastructure as code. Your choses to do infrastructure as code are Chef (Ruby), Puppet (Ruby), CFEngine (C), and BCFG2 (Python). You will not get very far with DSL-only knowledge of Chef of Puppet only. The case is the same with CFEngine and BCFG2. All infrastructure as code frameworks assume you are going to customize.
As for the resources, the most valuable resource these days is engineering time. Chef specifically and Ruby toolchain overall are hyper-efficient when it comes to engineering time.
Infrastructure as code can be implemented any way you want. The DSL portion of chef should get you very far, if it doesn't you should just be writing ruby, C, or python code to meet you needs.
Automation is really what devops is about; infrastructure as code, continuous integration, continuous deployment are all just synonyms for automation. I think again, what ever get the job done the most reliably, and quickest.
I'll give you a Chef example of why DSL is not going to get you far.
Let's say you are running a LAMP stack. Let's say your engineers are good enough to implement a Service Oriented Architecture. SOA means your infrastructure needs to be capable of running a variety of disjoint components. As a DevOps Engineer you need to be able to automate infrastructure and deployment to support rapid releases of application services.
From the infrastructure perspective, application services needs are similar. An application service will probably require a set of Hosts/VMs with specific roles, Vhost configuration, DNS provisioning, Load Balancer config, Logging configuration, User configuration, etc.
If you are writing just in DSL you will end up for a unique Chef recipe for every application service. These recipes are going to be 90% similar, and your Chef repo will become very difficult to maintain because many changes will require edits of multiple recipes (copy-pastes mostly).
Now, if you move beyond Chef's DSL, you will be able to extend Chef's DSL with your own definitions.
My Chef's recipe for a new LAMP application service is php_app "name" do ... that sets up DNS, Vhosts, logging, users and everything required in one command. The code is also very maintainable. To change the way logging is done for all application services, I need to edit only several lines of code in the Chef definition.
DevOps movement started as idea to adapt developer practices in systems administration. One of the principles developers use is DRY (Don't Repeat Yourself). In order to DRY you need to know more than basic Chef DSL.
By design, Chef fully expects you to leverage Ruby if you are operating in an environment of any complexity. Herein it differs from some other configuration management tools which strive to model everything you would want to manage. We (I am a Chef developer) often refer to our resources as primitives, the building blocks with which you code your infrastructure.