Metadata Card

• Prerequisites: Vol 1 Programming Basics (variable types, function signatures), Vol 3 Computer Systems (memory layout, CPU instruction basics)
• Estimated time: 50 minutes
• Core difficulty: Advanced
• Reading mode: High focus
• Optional skip: If only interested in practical use, the Hindley-Milner brief at the end of "Type Inference" can be skipped
• Completion mark: Can distinguish static/dynamic, strong/weak typing; can explain the fundamental difference between Java generic erasure and C++ template instantiation

Your Progress

You walk through a corridor covered in cobwebs and push open the first door of the Language Ruins. The etchings on the wall are dense—different languages have wildly different ways of writing type rules, but they all start from the same question: how do you ensure the data in your code is "correct"?

Your Task

Intuitively, a type is "the kind of variable"—numbers are one kind, strings are another. But this intuition is too shallow. What type systems really answer is: before a program runs, how do you know it won't make mistakes? This chapter takes you through three dimensions of type systems and helps you understand why different languages took such different paths.

Chapter Layers

• Required: Four quadrants of type systems (static/dynamic, strong/weak), type inference, generic implementation comparison
• Optional: Nominal vs structural typing
• Advanced: Hindley-Milner type inference core logic (brief overview only)

Breaking Ground · Tracing the Origin

You write a piece of code:

int x = "hello"; // type error

The Java compiler rejects it outright. You try the same idea in Python:

x = "hello"
# no problem

But being able to run doesn't mean it's always correct:

def add(a, b):
 return a + b

add(1, 2) # 3
add("hello", 2) # TypeError: can only concatenate str (not "int") to str

It blows up on the third line. This is why type systems exist: to catch as many errors as possible before the program runs.

---

Four Quadrants

Type systems are usually measured along two dimensions:

	Static	Dynamic
Strong	Java, Rust, Haskell, C#	Python, Ruby, Lua
Weak	C, C++	JavaScript

Static vs Dynamic: Whether type checking happens at compile time or runtime.

Strong vs Weak: Whether the language allows implicit type conversions that can "dismember" data.

C is static, weak:

int x = 65;
char c = x; // c = 'A' — compiler doesn't stop you, numeric value treated as ASCII

C gives you full control—including the right to make mistakes. The compiler won't say "are you sure you want to treat an int as a char?" It just converts based on memory layout. This is the hallmark of weak typing: type boundaries can be bypassed.

JavaScript takes this even further:

1 + "2" // "12"
1 - "2" // -1

The same operators, plus and minus, react completely differently to mixed types. JavaScript does massive implicit type conversion—convenient when writing quick prototypes, but in large projects, you're never sure whether a "2" is a string or a number.

Multi-language comparison window (value of static strong typing)

Rust's stance in this scenario is completely different. It doesn't silently convert for you like C; it requires your explicit signature:

let x: i32 = 65;
let c: char = x as char; // You must explicitly write `as` to convert

Rust allows conversion, but you must clearly state "I intend to do this." The compiler doesn't guess your intentions.

---

Type Inference

You might think: isn't Java's int x = 5 too verbose? The type is right there on the right-hand side with the 5; why write it on the left?

var x = 5; // Java 10+

This is type inference—the compiler infers the type from context, so you don't have to write it.

But type inference isn't a toggle (on or off); it's a spectrum:

Language	Inference power	Example
C++ (auto)	Local variable inference	auto x = 5;
Java (var)	Local variable inference	var x = 5;
Rust	Full inference (including generics)	let x = vec![1,2,3];
Haskell	Global inference (Hindley-Milner)	x = 5 — compiler knows the type
TypeScript	Inference + optional explicit annotations	let x = 5 is number type
Python	No compile-time inference (but type annotations)	x: int = 5 is annotation only, not checked

Rust's type inference goes much further than Java:

fn sum(v: &[i32]) -> i32 {
 v.iter().filter(|x| x % 2 == 0).sum()
}

The compiler knows the closure for filter returns bool, knows sum() returns i32—you don't need to write a single type annotation.

The core trade-off of type inference: the more inference, the less code you write, but compiler error messages may be harder to understand—when the compiler infers a different type than what you expected, you need to be able to read the compiler's reasoning process.

---

Advanced: A Glimpse of Hindley-Milner

Haskell and OCaml use the Hindley-Milner type inference algorithm. It's only a few hundred lines of code, but can reconstruct complete type information from a program without any type annotations.

The core idea is extremely simple: starting from known types, derive unknown types through constraint propagation.

let f x = x + 1

The compiler sees the + operator and knows its two operands must be of the same type. It sees 1 is an integer. Therefore x must be an integer, and f returns an integer.

If it encounters a contradiction—like using f "hello"—the compiler finds during constraint propagation that x would need to be both Int and [Char], and reports a type error.

You don't need to memorize the algorithm details. Just remember: type inference is not magic; it's constraint solving.

---

Generics: Same Word, Completely Different Implementations

Generics let you write a function that handles data of any type:

public class Box<T> {
 private T value;
 public void set(T value) { this.value = value; }
 public T get() { return this.value; }
}

Behind this craft, the compilers of different languages do completely different things.

Java: Type Erasure

// After compilation, roughly equivalent to:
public class Box {
 private Object value;
 public void set(Object value) { this.value = value; }
 public Object get() { return this.value; }
}

Java's compiler checks type safety at compile time, then erases the generic information in the bytecode. At runtime, Box<Integer> and Box<String> are the same class.

Advantage: Generics don't require modifying the JVM and don't break backward compatibility.

Cost:

• Can't get the type parameter at runtime (T.class is not valid)
• Can't create generic arrays (new T[10] is not valid)
• Primitive types must be boxed (Box<Integer> instead of Box<int>)

C++: Template Instantiation

template<typename T>
class Box {
 T value;
public:
 void set(T v) { value = v; }
 T get() { return value; }
};

C++'s compiler generates separate code for each different T:

Box<int> bi; // compiler generates Box<int> version
Box<double> bd; // compiler generates Box<double> version

Advantage: Each type gets optimal code (no boxing, no wrapping), can handle primitive types.

Cost: Code bloat—N different types produce N copies of binary code; slow compilation; error messages longer than novels.

Rust: Monomorphization (Similar to C++)

struct Box<T> { value: T }

Rust also takes the instantiation route—separate code for each T. But it adds a critical constraint: trait bounds:

fn print_value<T: Display>(value: T) {
 println!("{}", value);
}

T: Display tells the compiler: only types that implement the Display trait can use this function. This makes Rust's compiler error messages an order of magnitude better than C++ templates—because constraints are declared on the signature, not discovered only after template expansion.

---

Nominal vs Structural Typing

Two structures that are completely identical—are they the same type?

Java asks "what's your name"—if the names are different, they're different things, even if they look identical:

class Meters { double value; }
class Seconds { double value; }

Meters m = new Seconds(5.0); // Compile error — Meters and Seconds are different types

TypeScript does the opposite—it asks "what do you look like"; if they look the same, they can be interchanged:

interface Meters { value: number; }
interface Seconds { value: number; }

let m: Meters = { value: 5 };
let s: Seconds = { value: 3 };
m = s; // Type compatible — same structure is enough

Java says "what's this thing's name"—different names mean different things. TypeScript says "what does this thing look like"—identical structures can be swapped.

What does this difference mean in production?

Nominal typing is better for large projects—you can't accidentally assign Seconds to Meters. Structural typing is more flexible—you don't need to declare interface relationships in advance. Rust takes a middle path: nominal type main body + trait constraints as structured behavioral contracts.

---

Common Pitfalls

1. "Dynamic typing means no types" — Every Python object has a type at runtime (type(obj)), only variables lack type annotations
2. "Generic erasure = generics are syntactic sugar" — Close in Java, but in C++/Rust, generics are a code generation engine
3. "Structs that look the same can be swapped" — This only holds in structural type systems; Java/C++/Rust are all nominal

Pass Challenges

• Warm-up: Make a table showing where three languages you commonly use sit on the static/dynamic, strong/weak, nominal/structural dimensions
• Hands-on: In Java, create a List<Integer>, try to get its Class and see if it's List.class—experience type erasure
• Observe: In C++, create std::vector<int> and std::vector<double>, use sizeof to see instantiated memory sizes

Traveler's Notes

The essence of type systems is not "kinds of data" but the ability to find errors early—static/dynamic determines when they're found, strong/weak determines whether they can be bypassed, generics determine how many times you write it once.

→ Next Stop Preview

Types guarantee the "shape" of data—but where does data live, how is it allocated, and how is it freed? Push open the second door of the ruins: Memory Model & Runtime, and see how languages manage memory.