We should tackle is the difference between an interpreted language vs a compiled language.  There are some specific semantics to get under your belt as part of your language selection process.  In the world of DevOps, I would say that there really is not an incorrect choice here, but; DevOps is all about flow and your choices here can have an impact on your desired technology flow.

Regardless of where this article takes you, there really is no right answer to this question. I believe that the most important aspect to focus on is to promote software quality by getting your common tasks into a source code repository so that it is traceable.

Related Articles

What is an Interpreted Language?

An interpreted language requires that a separate runtime be installed on your system which will generally perform a JIT runtime on the code you have written.  

If I am writing code in Python, and I want that python to run on a remote Linux system, I need to have both the Python runtime installed on the remote system along with ensuring my code also exists on that system.

There is some practical utility to this.  Your systems require a dependency like Python, PHP, Ruby, Bash, etc. to be installed on the remote system, but you get a pretty good guarantee that you can write code once and use it in many places across many architectures.  The architecture (x86, ARM, SPARC, etc) has the runtime binaries installed (Python) and Just In Time "compile" (interprets) your code to be run on that architecture.  Pretty neat right?

In my opinion, interpreted languages are going to be some of the best programming languages for DevOps. As long as the server or host you are going to run your code on has the interpreter installed, the process is as simple as copy > paste > run!

What is a Compiled Language?

A compiled language requires that a full compilation happens prior to the code being runnable.  In Windows land, think about this like a .exe file, or on Linux, this would be a binary.  

If I am writing code in C++, and I want to run by C++ on a remote Linux system, I have 2 options.  I can install C++ on the remote system, add my code to that system, run a compile step, and finally run my binary.  Alternatively, I could compile my binary locally (ensuring I match the OS and CPU architecture as part of the compile step) and then distribute that binary to the remote system for execution.

Generally, a compiled language will be statically linked which means that there are zero additional dependencies that need to live on a remote system, unlike an interpreted language.  You do need to have a more detailed understanding of the remote system you will be deploying to so that your pre-compiled binary has a much better shot of being able to run on the destination.

Compiled languages are generally not the best languages for DevOps, at least not for beginners. When starting out, you are going to go through a lot of trial and error. This means a lot of wasted time also fighting compilers. I would recommend waiting on compiled languages until you have a bit of experience under your belt.

Platform Independence

Interpreted languages provide a high degree of platform independence, as the same code can be executed on multiple platforms without modification. This makes the development process much easier and faster, as you don't have to compile the code for each target machine you want to run it on.

Compiled languages, in contrast, are typically restricted to one type of computer or operating system. However, they still provide many advantages over interpreted languages and are often used to optimize performance and reduce memory usage. With the ever-growing complexity of software development, being able to use both compiled and interpreted languages is essential for any DevOps team.

In my opinion, this is the critical juncture for choosing between performing DevOps tasks with interpreted vs compiled languages. You should choose the programming language which fits the ecosystem your primary application is written in. Choosing different programming languages can be expensive and time-consuming for the team to continually context switch.

Catching Errors

The development process for compiled languages definitely has its benefits; catching errors at the time of compilation makes it much easier to debug and fix any issues since it can be done before the code is executed. This can be a critical benefit for some DevOps teams, as it can be done before the code is executed and saves time trying to debug errors at runtime.

On the other hand, Interpreted languages have their own set of advantages too. They catch errors at runtime, which gives DevOps teams a chance to identify and troubleshoot problems quickly and efficiently. Utilizing an interpreted language, teams may be afforded the opportunity to fix issues in place without needing to fully recompile a full application.

Fortunately, some interpreted languages also support compiling options which allow developers to leverage the benefits of both compiled and interpreted languages for their projects. This hybrid approach allows for improved speed and robustness when developing or maintaining software.

Do You Have A Need for Speed?

Compiled languages are generally going to be faster than interpreted languages.  A compiled application or script does not need to get converted from human-readable text into a binary that the CPU will understand.  That compilation was done when the application was built.  An interpreted language is going to need some kind of JIT compilation in order to be executed through the language's runtime.  In the PHP world, this JIT compilation is transforming human-readable text into OpCode.  Once that OpCode is created then the PHP runtime can just execute what the OpCode tells it to execute.

When trying to do tool selection, there is generally an argument about the speed an application runs and whether the right tool is the fastest tool.  When doing DevOps where you are generally trying to get a machine or environment into a specific state, the speed of the language itself is generally not your biggest impediment.  Your biggest bottleneck will be remote resources like packages, downloads, etc.  I would rather choose the right tool for the job inside of the ecosystem that I work in instead of trying to make my tool selection for DevOps based solely on performance.

Conclusion

Regardless of your choice between an interpreted programming language or compiled programming languages; make sure you are writing human-readable code which is readable and reusable. Tracking your change management via commit history, automagically pushing out changes when app changes are pushed, and reducing common tasks down to code will free the team up to work on tasks that really matter.