How Ruby is beating Python in the battle for the Soul of System Administration

I'm not persuaded that the arrow of causality has been drawn correctly here.<p>I.e., it seems rather that Ruby has gained a high profile in system administration, not due to any inherent characteristics of the language or library, but because Puppet and subsequently Chef happened to be written by people who wanted to use Ruby.<p>Based on TFA, this was a matter of taste. I can't, for example, see why it should particularly matter for system administration whether "‘len’ was a function instead of a method)." It doesn't. But the fact that the guy who went on to write a reasonably important tool preferred to do so in Ruby on the basis of such personal prejudices made Ruby important just insofar as the tool was important, and probably contributed to Chef being written in Ruby as well.<p>Most of the reasoning in this article is no better than complaining that len() is a builtin. I fail to see how Perl-golf style conciseness is inherently more "productive" (particularly when it makes it harder to understand and maintain operationally important software). I fail to see how the crushing burden of spelling out 'import re' makes regex unacceptably distant in Python. I fail to see how Ruby is inherently stress-relieving or better for people who use vi, and if you don't think there is magic in Python that is probably because you have not gotten that deeply into the language. All this is pretty spurious, I think.<p>And if I wanted Perl, then Perl is the best possible Perl, already familiar to tons of sysadmins; and lots of good things are happening in Perl development.<p>What isn't spurious is if you happen to like Ruby, even if only for stupid reasons like Luke's; or if you really want to work with a tool like Chef that requires you to write Ruby. Those are perfectly good reasons for using Ruby.<p>But multiple languages will be used into the far future. In reality, the reason that Ruby and Python (and for that matter Perl) are so frequently put head-to-head is because they are so very similar in their abilities. That's okay. Write what you like.

This is a rather misguided article. Unless everything has completely changed, Ruby is used for almost nothing in mainstream Linux. Bash and Python dominate "stock" system management code, and Bash and Perl seem to dominate for top-level add-on scripts written by a given sysadmin.<p>I've never even heard of any of those Ruby projects besides puppet, and I've only ever once installed Ruby- to support some obscure v0.03a library a developer wanted to try.<p>(Was a part-time sysadmin for 2 years)

Neither Python nor Ruby are best suited for one-liners that the author is emphasising. One liners are bash-fu or commandline-fu. Anything above 100 lines (just a figure from the article) is what Python or Ruby should be used for.<p>Last 10 lines in a file? 'tail -10 filename.txt'<p>Right tools for the right job.<p>As to Python vs Ruby? I believe the argument isn't about the language (although I think Python is more 'sane' :) ), but the community that surrounds it. And I like the Python community.

As a sysadmin who uses Puppet for a few hundred servers, I strongly disagree with the assertion that "After spending 25% of your time working with Puppet, you will be much more likely to reach for ruby for your next scripting task." I'm not even sure how you reach this conclusion since Puppet uses a DSL and not Ruby. I've been using Puppet for a while now and I don't know and have never used Ruby, and I'm not planning to. Much of what you have written seems like you're really stretching to validate your decision to start using Ruby instead of Python, which I'm not even sure why it matters. Use what you/your organization prefers, otherwise it doesn't really matter.

This article should have the following title: "How Ruby is Beating Python in the Battle for my Soul as System Administration". The summary shows that the person has not been working in a team to manage many components:<p>&#62; Ruby's greatest strength is its amazing flexibility. There is a lot of "magic" in ruby and sometimes it is dark magic. Python intentionally has minimal magic. It's greatest strengths are the best practices it enforces across its community. These practices make Python very readable across different projects; they ensure high quality documentation; they make the standard library kick ass. But the fact is that we sysadmins need flexibility more than we need raw power or consistency.<p>As a sysadmin you insanely need consistency all over the place or you cannot scale. This is in fact why Fabric, Puppet and Chef were created in the first place, to have consistent and automatic ways to deploy on and maintain your systems.

I use puppet in a mostly Python shop. I like that it uses a DSL and not raw Ruby/Pyhton/etc. However, I diagree with TFA about Ruby becoming the dominant language for a very simple reason: all UNIX-like systems have sh and in recent ones it supports all the same things. Most distros which I would consider installing onto servers, managed workstations, etc. have a Python interpreter and a standard library which includes everything from process management to a web server. These two tools are ubiqutous. However, not many distros ship with Ruby installed. Writing a 200 line Ruby script means that it is noe <i>your</i> job to ensure you have Ruby on all your machines, not the dist maintainers'.

"Puppet and Chef are seeing rapid adoption" != "ruby is inexorably becoming the dominant scripting language for linux system administration."

The short/one-liner examples are more likely to be done from command-line shell, where they would be much easier:<p><pre><code> head -10 /path/to/file dmidecode | grep -iq vmware &#38;&#38; echo "is vmware" || echo "is not vmware" </code></pre> The list of projects written in each language has more to do with what else you use than the languages, e.g., if you are working with Ruby web apps you may use Rake and Capistrano. SCons, Mercurial, Bazaar, and YUM are all written in Python.

This essentially reduces to "it's easier to write a fluent, readable, flexible and powerful DSL in Ruby than it is in Python.<p>Sysadmin tools benefit greatly from using such a DSL as their interface vs custom parsers or configuration files.<p>Hence, Ruby is a good choice for these sorts of things.

There's one thing left to do: Write a better tool than chef or puppet and do it in Python. That or you know - use the correct tool for the job and be done with it.

The Python example is completely broken. It'd be something like:<p><pre><code> import os if 'vmware' in os.popen('dmidecode').upper(): print 'this is a vmware vm' else: print 'this is not a vmware vm' </code></pre> I like regexps as much as the next ex-Perl hacker, but sometimes a little string manipulation is a lot better.

Again, another article that has a lot of talk about CM systems (CFEngine, puppet, chef, etc) and no love for bcfg2.. which happens to be Python based.

After seeing backticks, %x and $? being used, I have to say Ruby, when employed like this, competes more with Perl than with Python.

Ruby and Python break backward compatibility too often even with minor language version upgrade. It's harder to maintain working language version across servers than do real sysadmin tasks.<p>Perl rocks and robust to that.<p>See Perl equvalent to Ruby's Capistrano/Puppet/Chef.. or Python's Fabric/func..<p>Rex - <a href="http://rexify.org/" rel="nofollow">http://rexify.org/</a>

Only a moron would refuse to use a good tool if it's written in a language that is not said moron's personal idol.<p>Except of course if the language is Java.

Apparently there is an unstated premise -- sysadmins using Powershell lack souls.

tl;dr; ruby is the new perl