숨은 제어 흐름도, 숨은 할당도 없습니다

Zig is known for two rules: no hidden control flow and no hidden allocations. Together they make code easy to read and trust.

Control flow is the order your code runs in. Hidden control flow is when calls happen that you cannot see on the page, surprising you later.

Zig has no operator overloading and no hidden destructors. If a function runs, you can see its call right there in the source.

There are no exceptions jumping across your program. To ignore or pass on a failure you write try or catch, so error paths are explicit.

An allocation reserves memory for your data while a program runs. Hidden allocations are ones a language does for you, silently, behind a simple call.

In Zig, code that needs heap memory takes an allocator as a parameter. If a function can allocate, its signature says so plainly.

Because you pass the allocator, you decide where memory comes from: a debug-checking one, an arena, or a fixed stack buffer.

Visible allocations make memory cost obvious, which is gold for performance tuning and for embedded targets that have no heap at all.

These rules mean you reason about code by reading it, not by memorizing hidden machinery. What you see is what runs.

Cleanup is explicit too. A defer statement schedules code to run when the scope ends, so freeing memory sits right beside the allocation.

The honest cost is a bit more typing: you thread allocators through your code. In return you get total clarity and control.

How do you know a Zig function might allocate memory?

No hidden control flow and no hidden allocations mean failures and memory are always visible. You read the code and know exactly what happens. ✨