A little while ago, I had a simple glue script to write. It wasn’t complicated, but it needed to do a number of things: a YAML config file, command line switches, connection to multiple database types, SFTP connectivity and PGP encryption. I don’t often think of myself as old, but after writing the script above in Perl, it was clear to me that my sysadmin scripting needed some updating. I’d dabbled in Powershell, have a solid foundation in bash, but I’ve always felt most comfortable in Perl for sysadmin tasks. I’ve written one or two in C#, but C# isn’t a scripting language, which I think is essential for sysadmin scripting.

So I put together some requirements for SysAdmin scripting:

1. Ubiquitous – it can’t be difficult to find or install on any system, regardless of OS or hardware
2. Human readable – a decent developer should be able to grok sysadmin scripts, even if it isn’t their strength
3. Versatile – good availability of reliable, maintained packages
4. Scriptable – easy to integrate into system shell, regardless of OS

There’s probably some other intangibles, but I think this is a fair list of the features that draw me to Perl when I think of sysadmin and glue scripts.

Let’s be a little critical of Perl for a moment, and see how well it actually succeeds at the above. It’s ubiquitous enough, easily installed on Linux, MacOS and Windows (WSL). It is arguably human-readable given a good Perl developer, though it can easily be anything but. To be fair, though, I think most languages are like that. It’s most important that the syntactic sugar exist, not that every developer use it. It is definitely quite versatile. I’ve used Perl for everything from simple GUI applications to database scripts to parsers. And it is scriptable. Put #!/usr/bin/perl at the top of your script and chmod +x. Voila, an executable, human-readable file.

So fine, it does what it’s supposed to do. Still. 20 years later. There’s a reason it’s called the Camel book, though. As described in the book, Camels smell a bit. And Perl is starting to smell. The CPAN archive is full of unmaintained projects by anonymous authors. No one knows it any more. I mentioned Perl to a coworker, and got a quizzical look in return. It’s time to move on to a more supported and maintained ecosystem.

By a happy coincidence, I am studying Groovy as I need to write some load testing scripts for JMeter. And as I go through the learning material, it’s more and more clear to me that Groovy is not only a viable sysadmin language, it’s almost a natural successor to Perl. Let’s quickly assess the requirements:

1. Ubiquity – yes, Java is everywhere, and anywhere Java can be installed, Groovy can be installed
2. Human-readable – I’d argue much more so than Perl
3. Versatile – Using Grapes, the entire Maven repository is available. Maven seems to be far better managed than CPAN.
4. Scriptable – #!/usr/bin/perl becomes #!/usr/bin/env groovy and just like that, you have a new sysadmin language

Add to it good multi-platform IDE support (groovyConsole, IntelliJ, Neovim, VS Code) and I think we have a winner. There are many language features to make Groovy your new favourite script language. I know it is likely to be mine.