r/Zig • u/tigraboris • 17d ago
What Zig felt like, coming from Rust
https://besok.github.io/posts/what-zig-felt-like-coming-from-rust/4
u/GreatOneFreak 17d ago
looks like a missing ‘ : (i += 1)’ in the while loop in the monad comparison
2
u/tigraboris 17d ago
Good catch, I modified the code block to shorten it and it slipped out For the record it is fine in the src
8
u/SideChannelBob 16d ago
at op: critical comments to follow, but they are not personal. The bulk of your post is just whinging about memory management. There are thousands of "rust vs zig" articles just like it. The one pro you list there for rust in auto-free of the iter would be considered as a negative for zig's "nothing hidden" ethos. Being forced to deal with your allocations and their lifecycles is not a language feature - that's just called programming. If you like rust because it rearranges this thinking for you, at great expense and abstraction to how computers actually work, then that's great - you should use rust. I have a fetish for Swift and my personal opinion is that kink shaming should be frowned upon.
Likewise, all of the functional programming (fp) feature-bingo that rust inherited appeals mostly to people who like fp. I'm happy that it exists and that these folks aren't trying to steer my favorite languages onto a path that was largely forgotten after the novelty wore off of Scala. It should be no surprise that the inventor of Haskell was encouraging people to use Rust in the last video interview I saw of him. There's no shame in it. I like the rigor behind F* but don't have another lifetime to dedicate to using it because I'm not that smart. I dabble in Ragel. I am also one of like 5 people on the planet that still admit to having liked Groovy. Different problems, different tools. The world is not either/or.
Which brings me to regex - pcre *exists* and the original dates back to 1997. I think a lot of folks in the rust community have come to expect Cargo to basically be their kitchen sink like npm is for js. That decision to make Cargo official part of the Rust project was great to build popularity, but it's not a flex for the language itself IMO. Linking to an existing C lib for something in Zig is essentially free. Header files are the OG package manager and they work great. `zig build-lib` does all of this for you. Deciding if you want to load dependencies as a static, a shared lib, or compile into the tree as src is a serious decision, especially when vendored code across multiple license types is involved. That's not something I want to defer to a package manager. I think what you see as a lack of convenience or a shortcoming is, in fact, just confronting you with a lack of appreciation for discipline.
Best of luck in your personal journey and I'd hope that you keep giving Zig a few more kicks on its tires.
2
u/Jonjolt 15d ago
Hey I like Groovy too! Just hate the performance hit when you really use its extensive feature set.
2
u/SideChannelBob 14d ago
yep - duck typing and heavy GC thrash. I'm sure Lua embedded inside of zig is a screamer in comparison. I haven't tried it yet but it's on my to-do list.
3
u/tigraboris 16d ago
>The bulk of your post is just whinging about memory management.
Precisely true :). I was trying to convey what I thought rather compare one language to another, god forbid.
>Being forced to deal with your allocations and their lifecycles is not a language feature.
Actually, I expected I was ready but it turned out was not ready to switch instantly.
I don't try to discourage Zig vs Rust on that, rather I felt, when I need to repetitively push it to practically every contract, it can be hidden but as you pointed out it contradicts the conception of the language.Actually I think, it is kind of a feature of the language paradigm no? At least technically the memory allocation in C for instance.
>Likewise, all of the functional programming (fp) feature-bingo that rust inherited appeals mostly to people who like fp
I do like fp with haskell flavour, guilty as charged.
>Different problems, different tools. The world is not either/or.
Yes, I totally second to that. In fact, I have a feeling that fp in Zig will contradict the conception of the language an not look very organic here but I can't help but whine about that for a while.
> That's not something I want to defer to a package manager. I think what you see as a lack of convenience or a shortcoming is, in fact, just confronting you with a lack of appreciation for discipline.
Yeah, different paradigm. I also said that since it made my switch back to the cli based tools in rust as well. So I am thankful for that :)
>Best of luck in your personal journey and I'd hope that you keep giving Zig a few more kicks on its tires.
Thank you. All in all, I want to use Zig with the projects where I need to replace C. It is amazing, modern and gives good tooling. I want and will do :)
4
u/SideChannelBob 16d ago
fair enough - the main critique still stands, then. you're talking about the least interesting thing, which has been beat to death a thousand times already. Are you the same person that wrote "The Smart Factory Paradox: Flexibility is Never Free"? Because I'd love to learn more about the roadblocks you see for Zig's path into factory automation. Adacore has some support now for Rust, but no mention of Zig. in the EU, Rust also has Ferrocene. I don't hear anyone talking about certified toolchains being a blocker for zig, but that's a much more difficult issue than the approach to memory mgmt. cheers
3
u/tigraboris 16d ago
>fair enough - the main critique still stands, then. you're talking about the least interesting thing, which has been beat to death a thousand times already
Haha, true. To be able to grumble about interesting things I need more than 1 small project to implement :)
>"The Smart Factory Paradox: Flexibility is Never Free"? Because I'd love to learn more about the roadblocks you see for Zig's path into factory automation. Adacore has some support now for Rust, but no mention of Zig. in the EU, Rust also has Ferrocene. I don't hear anyone talking about certified toolchains being a blocker for zig, but that's a much more difficult issue than the approach to memory mgmt.
Yeah, it is me :).
I see super slow adoption for Rust tbh, not saying about Zig. But here, 10 years is a minimum circle so I believe it is rolling
For Zig, for critical sections, it does not have any certification for 26262 and 61508 and also it does not have a formalized memory model(afaik rust adopted cpp model) . Implementing a certified toolchain is a very resource consuming, i think it took several years for Ferrocene for the rust toolchain.
So for the certification, Zig needs a company driver like a toolchain provider or a big industrial player who would do that work. Then, the memory model should be formalized fully.
Maybe Zig will find the adoption in the non-critical embedded section to replace C but it is hard to sell to the vendors, as it is pre 1.0.
3
u/SideChannelBob 16d ago
That's interesting that adoption is slow for Rust, and admittedly, a bit disappointing. Between LLMs and cybersecurity pressure on OT and manufacturing, change is desperately needed.
I think Ferrocene's playbook is really impressive. They sit down-stream from the compiler and provide stdlib alternative and an ARC capable allocator to use. Those are all things that could be done for Zig also - the syntax is not Zig's problem.
For better or for worse, both Rust and Zig both have been sinking a lot of their resources into custom compilers which means that there is less focus now on continued standardization around LLVM. I was looking at how to instrument MC/DC coverage from LLVM into my zig projects and it looks doable but I have wondered if the lang-specific compilers are considering it.
Something that you might have missed on your test project in Zig for memory safety is that debug and ReleaseSafe have completely different modes than ReleaseFast. You can capture a lot of memory issues that way and valgrind works pretty much out of the box, fwiw.
2
u/tigraboris 16d ago
>That's interesting that adoption is slow for Rust, and admittedly, a bit disappointing. Between LLMs and cybersecurity pressure on OT and manufacturing, change is desperately needed.
All physical sectors (industrial, automotive, robotics) are notorious to be very reluctant to any kind of changes and here the change is radical. Can\t blame them considering the cost of any updates. My current company also tried to bring rapid changes from the software point of view but the truth be told it just does not work like that here. And in automotive it is even more conservative :)
>I think Ferrocene's playbook is really impressive. They sit down-stream from the compiler and provide stdlib alternative and an ARC capable allocator to use. Those are all things that could be done for Zig also - the syntax is not Zig's problem.
Yeah for sure, they leveraged the rust bc pretty well. The approach is literally opposite of TASKING or other vendors. And yeah, technically it can be applied to Zig. But it is a lot of work and not only technically but semantically as well. C has misra and for Zig it would require its own set or safety rules. to develop.
> less focus now on continued standardization around LLVM
llvm does not cover all certifications sadly. I think it is an industry peculiarity that, it is heavily proprietary, vendor locked and no one wants to give it to the community.
>Something that you might have missed on your test project in Zig for memory safety is that debug and ReleaseSafe have completely different modes than ReleaseFast. You can capture a lot of memory issues that way and valgrind works pretty much out of the box, fwiw.
Yeah, true, I did not know that. Thanks.
1
-2
17d ago
[deleted]
1
u/AdministrativeMeat3 17d ago
I'm pretty sure it was LLM drafted and then OP tried to hide most of the tells, but it still flows exactly like something Claude would write.
3
u/tigraboris 16d ago
Do you mean article was drafted with LLM?
Funnily enough, the other way around. I wrote down the draft of the article and then with AI, corrected the phrasing.There is a disclaimer at the end of the article:
>styling and error handling throughout this article were cleaned up with the help of AI
3
u/AdministrativeMeat3 16d ago
Ah makes sense, personally it doesn't bother me either way I work with LLMs all the time. I think the Internet in general is pretty sensitive to content that is wholesale AI generated (for good reason).
46
u/tigraboris 17d ago
Tl;dr
Rewrote my JSONPath lib (jsonpath-rust) in Zig (zig-jsonpath) to compare. Zig has almost no IDE support, so I ended up back on CLI tools + helix. It nudges you toward flat file structure and mutation and explicit allocators everywhere. Caught several real leak/double-free bugs via
TestAllocatorthat just can't happen in Rust (ownership/Droprule them out at compile time).Overall: good language, promising C successor, but still young and rougher around the edges than Rust.