Interpreted languages versus compiled languages

yujiri8 profile image Ryan Westlund Originally published at yujiri.xyz ・2 min read

I know some interpreted languages, some compiled languages, and some that can do both. But most languages can only do one. I know there are big benefits to both and I actually should have a bias toward interpretation as I was raised by Python and still have a soft spot for it. But I've grown to appreciate compilation much more. In fact, I've considered the opinion that interpreted languages should never have been invented. So I'm gonna count the benefits.


  • Can use without the clunk of writing a file, saving it to disk, running it, editing it and running it again from the start when it doesn't work, and then removing it

  • No danger of accidentally not rebuilding after a change and running the old binary. Much debugging time has been lost to that.

  • Portability. The same code can run on any operating system that has the interpreter. With a compiled language, different platforms get different binaries.

I used to also think interpreters had the benefit of not needing a separate compile step before running. But that's not true. Most compilers have an option to build and then run (and not save the built executable) with one command, and even if they didn't, it would be trivial to write a shell function for it.


  • Better performance

  • No dependencies. A program in an interpreted language always needs the interpreter to run; if you can compile to native code and link statically, you can ship a binary without worrying about dependencies on the target machine.

    This applies even to proprietary software that never runs on a client machine. At my job, our production server doesn't have the dependencies of our application installed. We use Go, so we build the server program into a single executable with no dependencies (other than libc and libthr) and just copy it over to the development server. We've had to copy over supporting binaries a few times too for one-time stuff, and I think those experiences would've been a lot worse if the prod server had to also have all the dependencies installed to run them.

  • Interoperability with other languages. This is the one that took me the longest to appreciate. Compiled languages have the option of compiling to a library that can be used by other languages, while interpreted languages don't.

    Now it's true, interoperability doesn't matter for application software. But it's misguided to dismiss that as an advantage here, because a language that can be used for both purposes is certainly better, all other things the same, than a language that can only write applications or libraries for itself. And it would be a terrible cost to have two languages in existence where one could cover both purposes. Even if the other language had advantages, they'd have to be massive for it to be worth having both.

Posted on by:

yujiri8 profile

Ryan Westlund


I'm a programmer, writer, and philosopher. My Github account is yujiri8; all my content besides code is at yujiri.xyz.


markdown guide

Revealing. I think I'm gonna learn Golang now. I've been putting it off way too long. 👌


Go Lang is a, pleasant surprise. Had to learn it for work. Like it better than C/C++ and Java. Only thing is pointers... 😰


I just went ahead and added that point to the post


I think both have their purposes. I‘m trying to look at both pragmatically.

When I think about interpreted languages such as JavaScript, I think about how easy it is to get started. You can get started literally in. minutes. This is why the language has massive popularity.

Interpreted languages are good or good enough for most purposes nowadays, where CPU and memory constraints are less of an issue anymore. More and more apps are running in the cloud: less people are concerned about the resource usages, just scale the servers. If slack, teams, vscode were invented 15-20 years ago, I think these apps wouldn’t be as popular as today because they eat so muchm CPU and resources that most people today don’t really care about anymore. Today’s CPU are fast for many purposes, RAMs are cheap.

I differentiate compiled languages into two: the ones that are compiled to machine language (C/C++, Fortran, BASIC, Pascal, Go, Rust, ...) and the ones that are to compiled to intermediate languages (Java, .net languages).

I think one of the practical benefits of the compiled languages is that you let the compilers do several things before you run your apps: checking variable/object initializations, checking syntax errors, checking uncaught exceptions, optimizing code, striping unused functions, etc. With interpreted languages you can just run your program without checking it and boom the interpreter catchea a syntax error in the production and stops running. To be honest though, good IDEs will catch many of these errors, doesn’t matter for compiled or interpreted languages.

I think systems programming and close to metal programming still needs to be done in compiled languages due to performance, resource usages. I work with embedded systems, where resources are nowadays are quite plenty (in an embedded sense) but is still constrained to low power requirements. So interpreted languages are still not options here.

Here’s my approach when choosing languages:
If I have low-power requirements OR close to metal OR low and limited CPU and memory OR need to squeeze performance of the hardware, I’d use C++, Go, Rust in that order.

If I have requirements for desktop, mobile, I‘d go whatever supported language of that paltform. Could be interpreted or compiled but I prefer compiled because I do really care about power requirements (battery) in mobiles and laptops. .net, C++, Java, swift etc.

For anything else: backend, web based frontend, small short running scripts, prototypes I’d use interpreted languages: python, PHP, JS, etc depending of platform. And whenever I need performance I can combine with compiled languages. Nowadays, interoperability with C/C++ libraries in not a big problem anymore, regardless of the language.