Top 5 programming languages for DevOps | Hacker News Reader

Top 5 programming languages for DevOps

opensource.com

15 pointsthmslee12 comments

Why are Go and C top five for DevOps? There's also no explanation as to why they're 'top' of anything.

I've never once written a line of Go or C to help me with an ops problem, but I'll tell you what I sure have written a lot of:

- Bash

- Perl (and sed and awk) for text manipulation

- Ant (Or Maven, Makefile, or MSbuild)

- Groovy for Jenkins pipelines

This list sounds more like "My Top 5 languages right now because I like them".

C is certainly out of place here as is any compiled let alone system programming language.

If you want to make a program that runs another program, i.e. forkexecs a process, how would you do it? You would want to drop privileges before exec, set resource limits, maybe chroot, maybe even seccomp, maybe pass sockets created in a privileged parent process, watch SIGCHLD in case it dies to restart it or start some sort of failover procedure, maybe also read its logs from stdout/stderr and do something with them. And what if you want to monitor a remote process like that and start it on another node if it stops responding? Would you use Bash for all of that? Perl - sure, but you would still have to write an extension in C to handle all of the OS specific things. I wouldn't use Go for that as it's going to be too much work, but its static binaries make it attractive for at least some of the infrastructural things.

python works fine for the more generic tasks like spawning subprocesses, parsing stdout/stderr, though the code can get a bit verbose when compared to bash scripts. Concerning the more OS specific bits and pieces, it really depends on what you count towards DevOps. In the article it is defined by the mantra "The infrastructure is configured, deployed, and managed through code". I would really hope you don't have to write a line of C code to achieve that. If you're developing tools for the DevOps space this is a different story of course.

Powershell is also curiously missing for the Windows or brave/adventurous Linux folks. Functional piped objects make some problems uniquely trivial.

I've never once written a line of Go or C to help me with an ops problem

Mostly true for me as well, but I sure have read a lot of C in my time. At the end of the day 90+% of all the underlying code I had to deal with was written in C and whenever it didn't do what I expected and I couldn't figure out why, I would pop the hood and take a look what it was going on. Also it was very handy to know C for all those times I had to try to get some 'Unix' application that was actually a Linux application compiled on not-Linux.

That being said I have no idea what Go is doing on the list.

The entire docker ecosystem is written in go. The ability to produce small statically linked binaries is a huge win if you have to distribute home grown command line tools.

I use docker every day, but I'm not committing patches to their source. The docker folks use Go to build their product and core libraries, but I wonder how much of their ops functionality is written in Go.

I use Linux binaries in every bash script I write, but I'm not writing C. I'm stringing other people's products together with my ops glue code.

That pretty much sums it up. The author says rather early in the article, "At this point, I am by no means a full time developer, and I'm not even sure I could call myself a hobbyist. But thanks to the resources I present in this article, I have moved beyond the point of basic knowledge."

So this is basically a list of languages they've found to be the most useful at their (low) level of expertise, and very likely this holds true for their worksite, which is a sample size of one.

There's a natural progression from Bash to Perl to Python, each more powerful than the previous. If you haven't made it to Python yet, you're stuck in the past.

Again with Ant and Maven, the progression is on to Gradle. Gradle, like Jenkins pipelines, uses Apache Groovy (minus its collections API), but Kotlin and IntelliJ are fast replacing it.

As for Go, its http server API is top of the line. If you use it instead of PHP or Rails, your app will scale seamlessly.

> There's a natural progression from Bash to Perl to Python, each more powerful than the previous.

As someone who moved in the opposite direction, I can't disagree more strongly.

Python is great if you want to write programs, but that adds a huge overhead over time, even in a simple language.

When I started using Perl, I feel like I really became a DevOps engineer. I built an automated test framework, deployment and monitoring tooling. I wrote scripts to automate processes large and small. It was the perfect scratchpad for getting an idea down with a working implementation, it was as free form or structured as I wanted it to be at any time.

Over time, my familiarity with Bash started to cover a lot of the smaller Perl tasks I was used to.

To automate some simple testing of a REST API, is Python / Perl _really_ needed?

A simple bash script could read data from a text file, then run curl commands in parallel while logging failures. Hell, use jq and you can process the JSON responses trivially too.

If Bash lacks power, I haven't ran into many situations where this was my issue.

I guess I just naturally skipped over Python because I use it for many things- it just didn't stick out in my brain as a tool I use when solving Ops problems, but I certainly do.

That being said, Python isn't necessarily available on all platforms, and for the vast majority of typical ops problems Python is way overkill. I prefer to reach for the least moving parts and most widely available first. I have an entire library of simplistic solutions to the vast majority of my issues that have evolved and stabilized over time, they're as battle tested and ready to go as anything I'm going to encounter heading up the complexity chain.

You're not a full time Java developer who has to work with many clients and projects if you believe Gradle is taking over from Maven. I like Gradle, and I use Gradle for most things, but I have seen it used MAYBE twice in the last 5 years by projects that have come through my company. Most CI/CD tools, if they support Gradle natively, don't have near the level of integration as Maven.

Don't assume I'm knocking Gradle, I much prefer it to Maven for simple projects, but good freaking luck if you've got a complicated project layout and you're importing it into IntelliJ. Even the latest 2017 update still has major issues with Gradle resolution that require me to blast my cache and restart.

I fail to see how using Go as your HTTP web application is using it for ops in the way you describe, unless you're using it as a request router of sorts. You're talking about building a web service/app in Go, which is great- but not what I was thinking of in the context of building tools to build, deploy, version, and release your applications and source code.

Reply on news.ycombinator.com