Zig's generics cause bloat just like any other language with generics--explicit flow control has nothing to do with it.
Zig is a good language. So are Rust, D, Nim, and a bunch of others. People tend to think that the ones they know about are better than all the rest because they don't know about the rest and are implicitly or explicitly comparing their language to C.
Zig's generics can potentially, but not necessarily, because Zig's generics are explicitly controlled through comptime functions, which give the developer a ton of control of how the generic code is unrolled. They're also frequently less used in general than Rust generics.
Of course both Zig and Rust are good languages. But my experience, and I believe your experience will be too if you try to compile programs of similar complexity using standard practices of each language, is that Zig compiles much more compactly in .ReleaseSmall mode than Rust does even with optimization flags, which makes it more ideal for embedded systems, in my opinion. I learned this on my own by implementing the same library in both languages using standard default practices of each.
Of course, at the desktop runtime level, binary size is frequently irrelevant as a concern. I just feel that since Zig makes writing "magic" code more difficult while Rust encourages things like macros, it is much easier to be mindful of things that do impact binary size (and perhaps performance).
Rust has macros that allow for arbitrary compile-time generated code, just like Zig. Most Rust-compiled programs are a bit bloated because libstd is statically linked and not rebuilt from scratch with a project-specific trimmed feature set, which leads to potentially unwanted code being included for e.g. recoverable panics, backtraces, UTF-8 string handling etc. A set of new RFC's is being worked on that may at some point allow libstd to be rebuilt from scratch within Stable Rust projects, with well-defined, stable, subsetted features.
> Rust has macros that allow for arbitrary compile-time generated code, just like Zig.
This is not true. Zig, D, and Nim all have full-language interpreters built into the compiler; Rust does not. Its macros (like macros generally) manipulate source tokens, they don't do arbitrary compile-time calculations (they live in separate crates that are compiled and then run on source code, which is very different from Zig/D/Nim comptime which is intermixed with the source code and is interpreted). Zig has no macros (Andrew hates them)--you cannot "generate code" in Zig (you can in D and Nim); that's not what comptime does. Zig's comptime allows functions written in Zig to execute at compile time (the same functions can also be used to run at execution time if they only use execution-time types). The Zig trick is that comptime code can not only operate on normal data like ints and structs, but also types, which are first class comptime objects. Comptime code has access to the TypeInfo of types, both to read the attributes of types and to create types with specified attributes, which is how Zig implements generics.
Zig is a good language. So are Rust, D, Nim, and a bunch of others. People tend to think that the ones they know about are better than all the rest because they don't know about the rest and are implicitly or explicitly comparing their language to C.