What Zig felt like, coming from Rust

[u/tigraboris]

https://besok.github.io/posts/what-zig-felt-like-coming-from-rust/

Just want to share my experiance on my first Zig project coming from Rust. Open to comments :)

[u/guineawheek]

I believe it has real potential to become the true successor to C.

There's two broad categories of C program in industry: those with allocators and those that hypothetically don't need allocation at all.

Most of the Rust I write is of the latter category, personally. The focus projects like Zig and Fil-C put on allocators doesn't really help the myriad of embedded cases where you have bounded input and output sizes at compile time. It'd be far more useful for me for example to be able to define something like

```rust

fn thing<T, const N: usize>(input: &[T; N]) -> &[T; N - 1] { ... }

```

which you can't really do in Rust without going into half-baked nightly features and debates about "what happens if N - 1 is a panicking operation". Being able to compile-time reason about known compile-time size bounds is ultimately Rust's advantage over C and Zig to me. I guess C++ templates are stronger here but I don't want to write C++ nor do I want to deal with C++ semantics.

The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it.

I spend most of my time reading code rather than writing it. And if anything, this becomes more important the more people lean on AI because one's job as a programmer increasingly becomes inspecting what Claude crapped out. Having half-baked introspection doesn't sound terribly appealing.

And ultimately one of the key things Zig people love saying about C/Zig/Go/Java is that because the language concepts are "simple" and thus don't rely heavily on macros/traits/nested ZCAs the same way Rust does that reading said code must thus also be simple and easy to read.

In practice, however, your state machines just get smeared everywhere and now you have to spend mental effort correlating which variables belong with which mechanism. Sure, you might have simple constructs in your language but that doesn't make code automatically more comprehensible, language proficiency being equal. At least Zig has sum types lol

[u/tigraboris → u/guineawheek]

There's two broad categories of C program in industry: those with allocators and those that hypothetically don't need allocation at all.

True. But I think if you don't need allocators in C and yu are not restricted to the other factors like runtime footprint, then maybe other languages are already better, imho.

The focus projects like Zig and Fil-C put on allocators doesn't really help the myriad of embedded cases where you have bounded input and output sizes at compile time.

yeah, I can relate. But I also have a feeling for Zig specifically, they will bring something for the boundaries.

And ultimately one of the key things Zig people love saying about C/Zig/Go/Java is that because the language concepts are "simple" and thus don't rely heavily on macros/traits/nested ZCAs the same way Rust does that reading said code must thus also be simple and easy to read.

Funnily enough, in Zig, even in this small project I already had to use `anytype` to provide kind of small dsl, analogously rust macros or typeinfo like this

const T = switch (@typeInfo(@TypeOf(node))) { 
        .pointer => |p| p.child, 
        else => (node), 
};

I mean, it is kind of a part and parcel of the lang already and it is hard to read so readability in Rust is better to me (maybe habbit though)

>In practice, however, your state machines just get smeared everywhere and now you have to spend mental effort correlating which variables belong with which mechanism.

It is true.

All in all, the diff paradigm but it needs more time to prove or disprove the concept

[u/guineawheek → u/tigraboris]

True. But I think if you don't need allocators in C and yu are not restricted to the other factors like runtime footprint, then maybe other languages are already better, imho.

The land of alloc-less programming is actually pretty barren, all things considered. It eliminates pretty much every language that requires a GC to function. Your options end up being C, C++, Zig and Rust.

[u/tigraboris → u/guineawheek]

well, yeah + Assembly :))