컴파일 시간과 실행 시간 비교

Zig code lives in two worlds: things that happen while you compile, and things that happen while the program runs. Learning the split unlocks Zig's power. ⏱️

Run-time is everything that happens when your built binary executes: user input, file reads, and values you cannot know in advance.

Compile-time is work the Zig compiler does before a binary even exists. Some expressions get fully evaluated right there.

A simple expression with known values can be computed during compilation. Zig folds it into a single constant in the final binary.

A bare integer literal starts life as a comptime_int. It has arbitrary precision until you pin it to a sized type like i32.

Put comptime in front of an expression to demand it be evaluated during compilation. If it cannot be, you get an error.

A value read from input is only known when the program runs. You cannot ask the compiler to evaluate it at compile-time.

Compile-time is not just math. Zig can run loops and call functions at compile-time, as long as every input is known then.

Computing things during compilation means zero run-time cost. The answer is baked into the binary, so the program never recomputes it.

The same Zig syntax serves both phases. There is no separate macro language: compile-time code is just ordinary Zig run early.

Because Zig evaluates known code early, many mistakes surface as compile errors. You fix them before the program ever runs.

You write a constant equal to 7 times 24. When is that multiplication performed?

Zig splits work into compile-time and run-time. Known values can be computed early for free, while unknown ones wait for execution. 🎯