What is runtime environment (RTE)?
Tags: todayilearned, runtime
Published: 2021-09-30 09:52:55

***Runtime*** and ***runtime environment*** are some of the most overloaded terms in software development. I myself find it confusing. I later found out that the word ***runtime*** itself means many different things in many different contexts. On top of that, the fact that people often time choose to use the word ***runtime*** as short for ***runtime environment*** just further complicates the matter. I guess I can say that my confusion is totally justified. 😛

## What is runtime?
1. **Runtime - The Lifecycle**: The first meaning of ***runtime*** is with regards to program lifecycle. It refers to ***the period of time*** in which a program is ***executing*** in contrast to the period of time in which a program is ***compiled***. For example, we often distinguish ***compile error*** vs. ***runtime error***.
2. **Runtime - How long did it take**: When used as two words, ***run time*** refers to the raw ***execution time*** of a program. 

## What is runtime environment?
Runtime environment takes its meaning in the context of ***runtime - the lifecycle***. Therefore, runtime environment is the environment in which a program or application is executed. It's the hardware and software infrastructure that supports the running of a particular codebase in real time. A runtime environment loads applications and has them run on a ***platform*** - *hardware and software architecture that acts as a foundation upon which other applications, processes, or technologies are developed.* All the resources necessary for running a program independently of the ***operating system (OS)*** are available on the platform. Practically speaking, a ***runtime environment*** is a piece of software that is designed to run other software.

## Why do we need runtime environment?
We use a variety of computer programs every day, for tasks like photo editing, word processing, and calculation. It's expected that these programs run as fast and smoothly as possible under a variety of conditions. Since operating systems can differ significantly from each other, and even the same OS has many different versions, it's necessary for developers to adapt programs to each OS by using ***runtime environment***.

Therefore, ***runtime environment*** provides the following advantages:
* ***Cross-platform functionality***: Enables cross-platform functionality for applications, which simplifies the development process since the program does not need to be adapted to different OS.
* ***Identical user interfaces***: Allows programs to have identical user interfaces regardless of whether they're run on Windows, macOS, or Linux.
* ***Conservation of resources***: Allows similar applications to use the same runtime environments and share common components.

## How does a runtime environment work?
Your code is just code. Whatever you write, in whatever language you choose, needs to eventually execute on a computer. An application that's currently running interacts with the runtime environment via a runtime system. The ***runtime environment***, therefore, acts as the ***middleman*** between the application and the  operating system.

As soon as a program is executed, the ***runtime environment*** sends instructions to the computer's processor and RAM, and accesses system resources. A ***runtime environment*** provides various basic functions for *memory, networks, and hardware*. These functions are carried out by the ***runtime environment*** instead of the application and work independently of the OS. They include *reading and writing files, managing input and output devices, searching and sorting files, and transporting data via networks.*

> **Fun fact**: the individual modules of a runtime environment are saved in runtime libraries. In Windows, you can identify these libraries based on the extension `.dll` (dynamic link library); in Linux, they have the file suffix `.so` (shared object).

Just like programming languages, which have several layers of abstraction varying from low-level to high-level languages, ***runtime environments*** also have their own ***layers of abstraction***, *i.e., runtime environments have their own runtime environments.* We can look at software as a series of layers that sit on top of the system hardware. Each layer provides services that will be used and required by the layer above it.

As programming languages evolves, people wanted an environment that could handle additional tasks that felt cumbersome for developers. *Do you really enjoy using `malloc()` and `free()` to manage all your dynamic memory?* 😉 *Wouldn't some kind of automatic reference counting and garbage collection be extremely convenient?* This is the motivation for the development of the ***Java Runtime Environment (JRE).*** 

For example, let's say your application is written in JavaScript. **JavaScript** is a high-level language whose high-level runtime environment is **Node.js**. Node comes with fancy features like *a callback queue, and event loop, and a thread pool*. As a ***runtime environment***, Node itself has its own runtime environment. If you download the Node   binary for Linux, you'll find that it's just another ELF executable waiting to be run by the OS. So, JavaScript's runtime environment is Node, and Node's runtime environment is the operating system.

So we can say that the ***universal runtime environment*** for any kind of programmatic execution is the ***operating system***. The OS is the only way you can get the CPU to execute your code. The OS *ensures that your program gets sufficient memory, gets scheduled fairly, and doesn't disturbed its neighbors.* It doesn't matter if you're using **C, Python**, or **Node.js**. At the end of the day, the OS is ***everyone's runtime environment***.