프롤로그 - 외계인과의 대화

여러분이 외계인(CPU)에게 "밥 줘"라고 말하고 싶다. 그런데 이 외계인은 "010101"밖에 모른다. 두 가지 방법이 있다.

1. 번역가(Compiler) 고용: 내가 쓴 편지 전체를 밤새 번역해서, 다음 날 아침 외계인에게 "0101..."이 적힌 책을 준다.
2. 통역사(Interpreter) 고용: 외계인 옆에 서서, 내가 "밥"이라고 하면 즉시 "01", "줘"라고 하면 "01"이라고 말해준다.

프로그래밍 언어의 실행 방식은 이 두 가지 철학에서 시작되었다.

---

내가 겪은 혼란 - "왜 C는 빌드하는데 Python은 안 해?"

대학 시절, C 수업에서는 늘 gcc hello.c -o hello 하고 ./hello 두 단계로 실행했다. 그런데 파이썬 수업에서는 그냥 python hello.py 하면 바로 실행됐다. "이게 무슨 차이지?" 싶었다.

더 혼란스러웠던 건 Java였다. javac Hello.java 하고 java Hello 했는데, 이건 컴파일도 하고 실행도 하는데... 왜 C처럼 실행 파일(.exe)이 안 나오지? .class 파일은 뭐지?

그리고 누가 "JavaScript는 인터프리터 언어야"라고 했는데, V8 엔진 문서를 보니 "JIT Compiler"라는 단어가 잔뜩 나왔다. "대체 컴파일러가 뭐고 인터프리터가 뭔데?"

이 혼란을 정리해본다.

---

결국 이거였다 - 번역 시점의 차이

프로그래밍 언어는 결국 "언제 기계어로 바꾸느냐"의 싸움이다.

• Compiler (AOT): 실행 전에 미리 다 번역해둔다.
• Interpreter: 실행하면서 한 줄씩 번역한다.
• JIT: 처음엔 통역하다가, 자주 쓰는 부분만 나중에 번역해둔다.

이 세 가지만 이해하면 모든 언어의 실행 방식을 이해할 수 있다.

---

컴파일러 (Compiler) - "완벽주의 번역가" 제대로 파보기

대표 언어: C, C++, Rust, Go

이들은 AOT(Ahead-Of-Time) 방식을 사용한다. 실행하기 전에 모든 것을 결정한다.

작동 방식

// main.c
#include <stdio.h>

int main() {
    int a = 5;
    int b = 10;
    int sum = a + b;
    printf("Sum: %d\n", sum);
    return 0;
}

이 코드를 실행하려면:

# 1. 전처리 (Preprocessing)
# #include를 실제 코드로 치환
gcc -E main.c -o main.i

# 2. 컴파일 (Compilation)
# C 코드를 어셈블리어로 변환
gcc -S main.i -o main.s

# 3. 어셈블 (Assembly)
# 어셈블리를 기계어 오브젝트 파일로 변환
gcc -c main.s -o main.o

# 4. 링킹 (Linking)
# 오브젝트 파일과 라이브러리를 합쳐서 실행 파일 생성
gcc main.o -o main

# 5. 실행
./main

이 과정을 한 번에 하려면 그냥 gcc main.c -o main 하면 된다.

핵심은 실행 전에 이미 기계어로 번역이 완료된다는 것이다. 그래서 실행 속도가 빠르다.

왜 빠른가?

컴파일러는 코드 전체를 보고 최적화할 수 있다.

int compute() {
    int x = 10;
    int y = 20;
    return x + y;
}

컴파일러는 이 코드를 보고 "어? 이거 그냥 30이잖아?" 하고 아예 코드를 이렇게 바꿔버린다:

int compute() {
    return 30;
}

이런 걸 상수 폴딩(Constant Folding)이라고 한다. 실행 전에 이미 계산을 끝낸 거다.

단점 - 빌드 시간

대형 프로젝트(크롬, 언리얼 엔진)는 빌드하는 데 몇 시간이 걸린다. 코드 한 줄 고치고 테스트하려면 다시 몇 시간 기다려야 한다. 이게 진짜 고통스럽다.

그래서 Incremental Build(바뀐 부분만 다시 빌드), ccache(빌드 캐시), distcc(분산 빌드) 같은 기술이 발전했다.

---

인터프리터 (Interpreter) - "실시간 통역사" 더 알아보기

대표 언어: Python, Ruby, Early JavaScript

인터프리터는 소스 코드를 바이너리로 만들지 않는다. 실행기(Interpreter)가 소스 코드를 직접 읽는다.

작동 방식 (REPL: Read-Eval-Print Loop)

# hello.py
a = 5
b = 10
sum = a + b
print(f"Sum: {sum}")

이걸 실행하면:

python hello.py

내부적으로 Python 인터프리터는:

1. Read: a = 5 한 줄 읽기
2. Parse: "아, 변수 a에 5를 할당하라는 거구나"
3. Execute: 메모리에 a = 5 저장
4. Loop: 다음 줄로 이동
5. 이걸 파일 끝까지 반복

매번 코드를 해석하기 때문에 느리다. 특히 반복문:

# slow.py
total = 0
for i in range(10_000_000):
    total += i
print(total)

이 코드는 total += i를 1000만 번 해석한다. C로 짜면 이미 기계어로 번역되어 있으니 1000만 번 실행만 하면 되는데, Python은 1000만 번 해석+실행을 한다.

실제로 벤치마크 돌려보면:

# C 버전
gcc slow.c -o slow -O3
time ./slow
# 0.03초

# Python 버전
time python slow.py
# 1.2초

# 40배 차이

장점 - 개발 속도

하지만 인터프리터는 개발이 빠르다.

# test.py
x = 5
print(type(x))  # <class 'int'>

x = "hello"
print(type(x))  # <class 'str'>

같은 변수 x가 처음엔 정수였다가 문자열로 바뀐다. 이게 동적 타이핑(Dynamic Typing)이다. C에서는 불가능하다.

그리고 eval() 같은 마법도 가능하다:

code = "print('Hello from eval')"
eval(code)  # Hello from eval

실행 중에 코드를 만들어서 실행한다. 이건 컴파일 언어에서는 불가능하다.

---

내가 이해했던 순간: AST (Abstract Syntax Tree)

"그럼 인터프리터는 어떻게 코드를 이해할까?"

결국 컴파일러든 인터프리터든, 코드를 트리 구조로 바꿔서 이해한다. 이게 AST(추상 구문 트리)다.

예를 들어 a = b + 1을 만나면:

1단계 - Lexing (어휘 분석)

코드를 토큰(Token)으로 쪼갠다:

[IDENTIFIER: a]
[ASSIGN: =]
[IDENTIFIER: b]
[PLUS: +]
[NUMBER: 1]

2단계 - Parsing (구문 분석)

토큰을 트리로 조립한다:

      (ASSIGN)
      /      \
    (a)     (PLUS)
            /    \
          (b)    (1)

이 트리를 보면 "b랑 1을 더한 결과를 a에 넣으라는 거구나"라고 이해할 수 있다.

Python으로 AST를 직접 볼 수 있다:

import ast
import astpretty

code = "a = b + 1"
tree = ast.parse(code)
astpretty.pprint(tree)

# Output:
# Module(
#     body=[
#         Assign(
#             targets=[Name(id='a', ctx=Store())],
#             value=BinOp(
#                 left=Name(id='b', ctx=Load()),
#                 op=Add(),
#                 right=Constant(value=1)
#             )
#         )
#     ]
# )

바로 이 트리를 실행하는 게 인터프리터의 일이다.

---

와닿았던 개념 - JIT (Just-In-Time) - "똑똑한 하이브리드"

"인터프리터는 느리고, 컴파일러는 빌드가 귀찮다. 둘을 섞으면?"

Google V8(JavaScript)와 JVM(Java)이 선택한 방식이 JIT Compiler다.

작동 방식

// hotspot.js
function add(a, b) {
    return a + b;
}

let sum = 0;
for (let i = 0; i < 1_000_000; i++) {
    sum = add(sum, i);
}
console.log(sum);

V8은 이 코드를 실행할 때:

1. 초반: Ignition(인터프리터)로 실행. 빠르게 시작.
2. 프로파일링: "어? add() 함수가 100만 번 호출되네?"
3. Hot Spot 감지: "이건 자주 쓰는 코드야. 최적화하자."
4. JIT Compile: TurboFan(컴파일러)이 add() 함수를 기계어로 번역.
5. 캐싱: 번역된 기계어를 메모리에 저장.
6. 고속 실행: 다음부터는 기계어를 바로 실행.

이 덕분에 JavaScript가 과거보다 수십 배 빨라졌다.

주의 - Deoptimization (최적화 해제)

하지만 함정이 있다.

function add(a, b) {
    return a + b;
}

// 처음엔 숫자만 들어옴
add(1, 2);  // 3
add(5, 10); // 15

// V8: "아, 이 함수는 숫자만 받는구나. 정수 전용 기계어로 최적화!"

// 그런데 갑자기...
add("hello", "world");  // "helloworld"

// V8: "어? 문자열이 들어왔네? 최적화 무효화!"
// (Deoptimization 발생. 느린 인터프리터 모드로 복귀)

그래서 타입을 일정하게 유지하는 게 JavaScript 성능 최적화의 핵심이다.

// Bad (타입이 바뀜)
let x = 5;      // 숫자
x = "hello";    // 문자열 (Deoptimization!)

// Good (타입 일정)
let num = 5;
let str = "hello";

이걸 받아들였을 때 내 코드 스타일이 완전히 바뀌었다.

---

LLVM - "컴파일러의 레고" 파헤치기

"컴파일러는 어떻게 만들까?"

과거엔 새 언어를 만들려면 컴파일러를 처음부터 다 짜야 했다. x86용, ARM용, MIPS용... 지옥이었다.

그래서 등장한 게 LLVM이다.

LLVM의 3단계 구조

Source Code (C/Rust/Swift)
    ↓
[Frontend] → Parsing → AST → LLVM IR
    ↓
[Optimizer] → Dead Code Elimination, Inlining, etc.
    ↓
[Backend] → x86_64 / ARM64 / WASM Machine Code

핵심은 LLVM IR(Intermediate Representation)이라는 중간 언어다.

LLVM IR 예제

int add(int a, int b) {
    return a + b;
}

이 C 코드를 LLVM IR로 변환하면:

define i32 @add(i32 %a, i32 %b) {
entry:
  %sum = add nsw i32 %a, %b
  ret i32 %sum
}

이제 어떤 언어든 LLVM IR로만 변환해주면, LLVM이 알아서 모든 CPU용 기계어를 만들어준다.

그래서 Rust, Swift, Kotlin/Native 같은 언어들이 LLVM을 쓴다. 컴파일러를 처음부터 만들 필요가 없어진 거다.

---

WebAssembly - "웹 브라우저의 기계어" 뜯어보기

"웹 브라우저에서도 C++ 성능을 내고 싶다."

자바스크립트는 아무리 최적화해도 한계가 있다. 그래서 등장한 게 WebAssembly(Wasm)다.

기존 방식 (JavaScript)

C++ Code → (수동 변환) → JavaScript → Browser

문제: JavaScript는 동적 타입이라 느리다.

새 방식 (WebAssembly)

C++/Rust Code → (Compile) → .wasm → Browser

.wasm 파일은 바이너리다. 텍스트가 아니라 이미 컴파일된 기계어에 가까운 형태다.

실제 예제

// add.c
int add(int a, int b) {
    return a + b;
}

Emscripten으로 컴파일:

emcc add.c -o add.js -s EXPORTED_FUNCTIONS='["_add"]'

JavaScript에서 사용:

// main.js
const wasmModule = require('./add.js');

wasmModule.onRuntimeInitialized = () => {
    const result = wasmModule._add(5, 10);
    console.log(result);  // 15
};

속도 차이:

• JavaScript: 이미지 처리 1초
• WebAssembly: 이미지 처리 0.2초 (5배 빠름)

실제로 Figma, Adobe Photoshop Web, Google Earth가 Wasm을 쓴다.

---

GraalVM - "언어의 경계를 허문다" 한 걸음 더

"Java 코드에서 Python 라이브러리를 호출할 수 있다면?"

Oracle이 만든 GraalVM은 여러 언어를 하나의 VM에서 섞어 쓸 수 있게 해준다.

Polyglot 예제

// PolyglotExample.java
import org.graalvm.polyglot.*;

public class PolyglotExample {
    public static void main(String[] args) {
        try (Context context = Context.create()) {
            // Java에서 Python 코드 실행
            context.eval("python",
                "def greet(name):\n" +
                "    return f'Hello, {name}!'\n" +
                "print(greet('GraalVM'))"
            );

            // Java에서 JavaScript 실행
            Value result = context.eval("js",
                "const add = (a, b) => a + b; add(5, 10);"
            );
            System.out.println("JS result: " + result.asInt());  // 15
        }
    }
}

이게 가능한 이유는 모든 언어가 Truffle Framework라는 공통 인터페이스 위에서 돌기 때문이다.

Native Image

더 놀라운 건 Native Image다.

# Java 프로그램을 네이티브 바이너리로 컴파일
native-image -jar myapp.jar

# 결과 - JVM 없이 실행되는 단일 실행 파일
./myapp

• 일반 Java: JVM 부팅 5초 + 실행
• Native Image: 부팅 0.05초 + 실행 (100배 빠름)

서버리스(Lambda, Cloud Functions)에서 엄청난 이점이다.

---

적용 - 언어 선택 기준

내가 정리한 언어 선택 체크리스트:

C/C++/Rust (AOT Compiler)를 쓸 때

• 성능이 최우선 (게임 엔진, OS, 임베디드)
• 메모리를 직접 제어해야 함
• Garbage Collection 일시 정지가 허용 안 됨 (실시간 시스템)
• 예: 언리얼 엔진, Linux 커널, Chrome V8 엔진

Python/Ruby (Interpreter)를 쓸 때

• 개발 속도가 최우선 (프로토타이핑, 스크립트)
• 성능은 중요하지 않음 (I/O bound 작업)
• 라이브러리 생태계가 중요 (머신러닝, 데이터 과학)
• 예: 데이터 분석, 자동화 스크립트, Django/Flask 웹앱

Java/C# (JIT)를 쓸 때

• 서버 애플리케이션 (장시간 실행)
• 멀티플랫폼 지원 필요
• 엔터프라이즈 생태계 (Spring, .NET)
• 예: 은행 시스템, 대규모 웹 서비스, Android 앱

JavaScript/TypeScript (JIT)를 쓸 때

• 웹 프론트엔드 (선택지가 없음)
• Node.js 백엔드 (JavaScript 개발자 공유)
• 빠른 프로토타이핑
• 예: React 앱, Express 서버, Electron 데스크톱 앱

Go (AOT + GC)를 쓸 때

• 클라우드 네이티브 (컨테이너, 마이크로서비스)
• 빠른 빌드 + 빠른 실행
• 동시성 중요 (Goroutine)
• 예: Docker, Kubernetes, API 서버

---

비교 분석 - 한눈에 보는 차이

특성	AOT (C/C++)	JIT (Java/JS)	Interpreter (Python)
실행 속도	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
시작 속도	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
메모리 사용	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
개발 속도	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
이식성	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
디버깅	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
빌드 시간	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐ (없음)
최적화 수준	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐

---

요약

결국 컴파일러와 인터프리터는 "언제 번역하느냐"의 차이였다.

1. Compiler (AOT): 실행 전에 미리 번역. 빠르지만 빌드 필요. (C, Rust)
2. Interpreter: 실행하면서 번역. 느리지만 유연함. (Python, Ruby)
3. JIT: 둘의 장점을 섞음. 현대 언어의 표준. (Java, JavaScript, C#)
4. LLVM: 컴파일러를 모듈화하여 새 언어 개발을 쉽게 만듦.
5. WebAssembly: 웹에서도 네이티브 성능.
6. GraalVM: 언어 경계를 허물고 polyglot 프로그래밍 실현.

내가 이 개념을 이해했을 때, 더 이상 "이 언어가 더 빠르다/느리다"라고 단순하게 생각하지 않게 됐다. 각 언어가 어떤 문제를 풀기 위해 어떤 트레이드오프를 선택했는지 보이기 시작했다.

C++의 복잡한 빌드 시스템도, Python의 느린 속도도, JavaScript의 이상한 타입 시스템도, 모두 그들의 선택이 만든 결과였다. 그리고 그 선택이 옳았던 적절한 상황이 있다는 걸 받아들였다.

---

Compiler vs Interpreter: When I Finally Got the Difference

Prologue: The Alien Translation Problem

Imagine you need to tell an alien (your CPU) "Give me food." Problem is, this alien only understands binary: "010101..."

You have two options:

1. Hire a Translator (Compiler): They spend all night translating your entire letter, and the next morning, they hand the alien a book written entirely in "0101...".
2. Hire an Interpreter: They stand next to the alien. When you say "Give," they immediately whisper "01". When you say "food," they whisper "01" again.

Programming language execution models stem from these two philosophies.

---

My Struggle: "Why Does C Compile But Python Doesn't?"

In college, my C class always required two steps: gcc hello.c -o hello then ./hello. But in Python class, I just did python hello.py and it ran immediately. "What's the difference?" I wondered.

Java confused me even more. I had to do javac Hello.java then java Hello. It compiled AND executed, but why didn't it produce an executable file like C's .exe? What was this .class file?

Then someone told me "JavaScript is an interpreted language," but when I read V8 engine documentation, it was full of "JIT Compiler" terminology. "What even IS a compiler versus an interpreter?"

Let me break down what I learned.

---

The Aha Moment: It's About WHEN Translation Happens

Programming languages are fundamentally a battle of "when do you translate to machine code?"

• Compiler (AOT): Translate everything before execution.
• Interpreter: Translate line-by-line during execution.
• JIT: Start interpreting, then compile the frequently-used parts later.

Understanding these three models unlocks how every language works.

---

Deep Dive 1: Compiler (AOT) - "The Perfectionist Translator"

Representative Languages: C, C++, Rust, Go

These use AOT (Ahead-Of-Time) compilation. Everything is decided before execution.

How It Works

// main.c
#include <stdio.h>

int main() {
    int a = 5;
    int b = 10;
    int sum = a + b;
    printf("Sum: %d\n", sum);
    return 0;
}

To execute this code:

# 1. Preprocessing
# Replace #include with actual code
gcc -E main.c -o main.i

# 2. Compilation
# Convert C to Assembly
gcc -S main.i -o main.s

# 3. Assembly
# Convert Assembly to Machine Code object file
gcc -c main.s -o main.o

# 4. Linking
# Combine object files and libraries into executable
gcc main.o -o main

# 5. Execution
./main

Or simply: gcc main.c -o main does it all at once.

The key insight: translation to machine code completes before execution. That's why it's fast.

Why So Fast?

Compilers see the entire codebase and can optimize globally.

int compute() {
    int x = 10;
    int y = 20;
    return x + y;
}

The compiler sees this and thinks "Wait, this is just 30," and rewrites it as:

int compute() {
    return 30;
}

This is called Constant Folding. Computation happens at compile time, not runtime.

The Downside: Build Time

Large projects (Chrome, Unreal Engine) take hours to build. Change one line, wait hours to test again. It's genuinely painful.

That's why technologies like Incremental Builds (rebuild only changed parts), ccache (build caching), and distcc (distributed building) evolved.

---

Deep Dive 2: Interpreter - "The Real-Time Translator"

Representative Languages: Python, Ruby, Early JavaScript

Interpreters don't convert source code to binary. The interpreter engine reads source code directly.

How It Works (REPL: Read-Eval-Print Loop)

# hello.py
a = 5
b = 10
sum = a + b
print(f"Sum: {sum}")

When you run:

python hello.py

Internally, the Python interpreter:

1. Read: Read line a = 5
2. Parse: "Assign value 5 to variable a"
3. Execute: Store a = 5 in memory
4. Loop: Move to next line
5. Repeat until end of file

Because it interprets every time, it's slow. Especially in loops:

# slow.py
total = 0
for i in range(10_000_000):
    total += i
print(total)

This code interprets total += i ten million times. In C, the machine code is already ready, so you just execute ten million times. In Python, you interpret + execute ten million times.

Actual benchmark:

# C version
gcc slow.c -o slow -O3
time ./slow
# 0.03 seconds

# Python version
time python slow.py
# 1.2 seconds

# 40x slower

The Upside: Development Speed

But interpreters enable rapid development.

# test.py
x = 5
print(type(x))  # <class 'int'>

x = "hello"
print(type(x))  # <class 'str'>

The same variable x starts as an integer, then becomes a string. This is dynamic typing. Impossible in C.

And magic like eval() works:

code = "print('Hello from eval')"
eval(code)  # Hello from eval

Execute code generated at runtime. Impossible in compiled languages.

---

When I Understood: AST (Abstract Syntax Tree)

"How does an interpreter understand code?"

Whether compiler or interpreter, code gets converted into a tree structure for understanding. This is the AST (Abstract Syntax Tree).

For example, a = b + 1:

Step 1: Lexing (Lexical Analysis)

Break code into tokens:

[IDENTIFIER: a]
[ASSIGN: =]
[IDENTIFIER: b]
[PLUS: +]
[NUMBER: 1]

Step 2: Parsing (Syntax Analysis)

Assemble tokens into a tree:

      (ASSIGN)
      /      \
    (a)     (PLUS)
            /    \
          (b)    (1)

Reading this tree: "Add b and 1, assign the result to a."

You can visualize AST in Python:

import ast
import astpretty

code = "a = b + 1"
tree = ast.parse(code)
astpretty.pprint(tree)

# Output:
# Module(
#     body=[
#         Assign(
#             targets=[Name(id='a', ctx=Store())],
#             value=BinOp(
#                 left=Name(id='b', ctx=Load()),
#                 op=Add(),
#                 right=Constant(value=1)
#             )
#         )
#     ]
# )

The interpreter's job is to execute this tree.

---

The Concept That Clicked: JIT (Just-In-Time) - "The Smart Hybrid"

"Interpreters are slow, compilers require builds. What if we combine them?"

Google's V8 (JavaScript) and the JVM (Java) chose JIT Compilation.

How It Works

// hotspot.js
function add(a, b) {
    return a + b;
}

let sum = 0;
for (let i = 0; i < 1_000_000; i++) {
    sum = add(sum, i);
}
console.log(sum);

V8 executes this by:

1. Initially: Run with Ignition (interpreter). Fast startup.
2. Profiling: "Hmm, add() is called 1 million times?"
3. Hot Spot Detection: "This is frequently-used code. Let's optimize it."
4. JIT Compile: TurboFan (compiler) translates add() to machine code.
5. Caching: Store compiled machine code in memory.
6. High-Speed Execution: Subsequent calls execute machine code directly.

This made JavaScript dozens of times faster than before.

The Trap: Deoptimization

But there's a catch.

function add(a, b) {
    return a + b;
}

// Initially only numbers
add(1, 2);  // 3
add(5, 10); // 15

// V8: "This function only takes numbers. Optimize for integers!"

// But then suddenly...
add("hello", "world");  // "helloworld"

// V8: "Wait, a string? Invalidate optimization!"
// (Deoptimization occurs. Back to slow interpreter mode)

That's why keeping types consistent is crucial for JavaScript performance optimization.

// Bad (type changes)
let x = 5;      // number
x = "hello";    // string (Deoptimization!)

// Good (consistent types)
let num = 5;
let str = "hello";

When I understood this, my coding style completely changed.

---

Advanced Topic 1: LLVM - "The LEGO of Compilers"

"How do you build a compiler?"

In the past, creating a new language meant writing a compiler from scratch. One for x86, one for ARM, one for MIPS... absolute hell.

Then LLVM appeared.

LLVM's 3-Stage Architecture

Source Code (C/Rust/Swift)
    ↓
[Frontend] → Parsing → AST → LLVM IR
    ↓
[Optimizer] → Dead Code Elimination, Inlining, etc.
    ↓
[Backend] → x86_64 / ARM64 / WASM Machine Code

The key is LLVM IR (Intermediate Representation), an intermediate language.

LLVM IR Example

int add(int a, int b) {
    return a + b;
}

This C code converts to LLVM IR as:

define i32 @add(i32 %a, i32 %b) {
entry:
  %sum = add nsw i32 %a, %b
  ret i32 %sum
}

Now any language that can output LLVM IR gets machine code for all CPUs automatically.

That's why Rust, Swift, Kotlin/Native use LLVM. No need to write a compiler from scratch.

---

Advanced Topic 2: WebAssembly - "Machine Code for Web Browsers"

"Can we get C++ performance in web browsers?"

JavaScript, no matter how optimized, has limits. That's why WebAssembly (Wasm) was created.

Old Way (JavaScript)

C++ Code → (Manual Conversion) → JavaScript → Browser

Problem: JavaScript is dynamically typed, hence slow.

New Way (WebAssembly)

C++/Rust Code → (Compile) → .wasm → Browser

.wasm files are binary. Not text, but close to compiled machine code.

Real Example

// add.c
int add(int a, int b) {
    return a + b;
}

Compile with Emscripten:

emcc add.c -o add.js -s EXPORTED_FUNCTIONS='["_add"]'

Use in JavaScript:

// main.js
const wasmModule = require('./add.js');

wasmModule.onRuntimeInitialized = () => {
    const result = wasmModule._add(5, 10);
    console.log(result);  // 15
};

Speed difference:

• JavaScript: Image processing 1 second
• WebAssembly: Image processing 0.2 seconds (5x faster)

Real apps using Wasm: Figma, Adobe Photoshop Web, Google Earth.

---

Advanced Topic 3: GraalVM - "Breaking Language Barriers"

"What if Java code could call Python libraries?"

Oracle's GraalVM lets you mix multiple languages in a single VM.

Polyglot Example

// PolyglotExample.java
import org.graalvm.polyglot.*;

public class PolyglotExample {
    public static void main(String[] args) {
        try (Context context = Context.create()) {
            // Execute Python code from Java
            context.eval("python",
                "def greet(name):\n" +
                "    return f'Hello, {name}!'\n" +
                "print(greet('GraalVM'))"
            );

            // Execute JavaScript from Java
            Value result = context.eval("js",
                "const add = (a, b) => a + b; add(5, 10);"
            );
            System.out.println("JS result: " + result.asInt());  // 15
        }
    }
}

This works because all languages run on the Truffle Framework, a common interface.

Native Image

Even more impressive is Native Image.

# Compile Java program to native binary
native-image -jar myapp.jar

# Result: Single executable that runs without JVM
./myapp

• Regular Java: JVM boot 5 seconds + execution
• Native Image: Boot 0.05 seconds + execution (100x faster)

Huge advantage for serverless (Lambda, Cloud Functions).

---

Real-World Application: Language Selection Checklist

My personal language selection criteria:

Use C/C++/Rust (AOT Compiler) When:

• Performance is top priority (game engines, OS, embedded)
• Need direct memory control
• Garbage Collection pauses unacceptable (real-time systems)
• Examples: Unreal Engine, Linux kernel, Chrome V8 engine

Use Python/Ruby (Interpreter) When:

• Development speed is priority (prototyping, scripts)
• Performance doesn't matter (I/O bound tasks)
• Library ecosystem matters (ML, data science)
• Examples: Data analysis, automation scripts, Django/Flask web apps

Use Java/C# (JIT) When:

• Server applications (long-running processes)
• Multi-platform support needed
• Enterprise ecosystem (Spring, .NET)
• Examples: Banking systems, large web services, Android apps

Use JavaScript/TypeScript (JIT) When:

• Web frontend (no choice)
• Node.js backend (share JS developers)
• Rapid prototyping
• Examples: React apps, Express servers, Electron desktop apps

Use Go (AOT + GC) When:

• Cloud-native (containers, microservices)
• Fast build + fast execution
• Concurrency important (Goroutines)
• Examples: Docker, Kubernetes, API servers

---

Comparison Table: At a Glance

Characteristic	AOT (C/C++)	JIT (Java/JS)	Interpreter (Python)
Execution Speed	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
Startup Speed	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Memory Usage	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
Development Speed	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Portability	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Debugging	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Build Time	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐ (none)
Optimization Level	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐