> Rust teaches you ownership like a tough-love therapist. Zig, meanwhile, just shrugs and says, "You break it, you fix it." That's the philosophical divide. Rust assumes you can't be trusted. Zig assumes you're an adult.
Yep, just need programmers to roll up their sleeves and write code without errors. That's worked out great for the whole history of never. And I like Zig, but not this way.
This has a lot of hallmarks of contemporary-LLM-generated prose. I don't think it's bad in and of itself to use LLMs to generate writing, but the prose does come across as kind of repetitive and boring to read.
Anyway I don't see this as a rousing Zig endorsement. The Rust tooling and borrow checker and type system are complex to learn (and contribute to slow compile times which is a genuine downside of Rust), but give you huge benefits in terms of correctness guarantees. And I think people highly underrate the value of writing software that you can guarantee won't fail in certain ways.
I am personally more familiar with Rust than Zig, although I've looked into Zig some. I think that trying approaches to systems languages that are different from the design decisions Rust made is in general a very worthy project. Zig does trade off the amount of memory safety guarantees Rust has in order to have a simpler model of pointers, which is perhaps a reasonable tradeoff in a systems language although I still think the value of the Rust borrow checker is huge. I'm actually more annoyed in Zig by the lower amount of type expressivity compared to Rust - `Result<T, E>` is actually a pretty cool abstraction, and it sucks that you can't easily build this in Zig because of the lack of type level generics support (I'm aware you can do things with comptime to get something similar).
Again, my personal familiarity with Zig is limited and I'm aware the language is still in active development. I think I still prefer the design tradeoffs Rust makes; still, I support the Zig designers (and designers of Nim, Odin, and other novel systems languages) trying out different ideas, and users testing out these languages to build real software.
I'm currently designing and implementing an async library and I've been wondering what's better, structured concurrency or explicit scopes.
Explicit scopes allow you to see and think exactly how you want to relate every async task or not. But you have to pass it around, it's more verbose, and you can get mixed up in your scopes.
Structured concurrency handles it automatically, the structure of the code is implicitly the scope of your tasks. Less verbose, can't forget about it, or get it mixed up, but it's magical, you might not even realize it's happening, and understanding mentally what the scope ends up being requires you to understand really well how the structured concurrency implicitly infers your scopes.
Consider the explicit solution and a layer of sugar for making it implicit from structure, whether it's macros or a DSL or whatever. Abstractions work best when they stack.
> Rust assumes you can't be trusted. Zig assumes you're an adult.
> You can onboard a junior dev to Zig faster than you can explain Rust's Result<T, E> patterns to a senior.
Ahahahahaha. Oh wait, you're serious? Let me laugh even harder!
But seriously this article can't make up its mind. Zig built safety, except it isn't safe because it just trusts you. Zig assumes you're adult and doesn't help you, but also it's easy and anyone can do it!
The contradictions just keep flowing throughout this entire puff piece.
> That's it. No macros. No build.rs. No Cargo screaming about outdated crates.
> Deterministic build system that works like clockwork.
And what's that? Oh, Zig also has a lazily fetched package manager? And it encourages everyone to use nightly because it's not a stable language yet? Tell me more about how cargo complains too much about outdated crates.
This writing is absolutely too vapid (even as far as AI slop goes), especially for the kind of jabs it makes at Rust.
Zig is not the end solution to all problems, just like neither Rust is.
Each is a sweetspot on the spectrum of possible solutions, each with it's own sets of pros and cons that appeal differently to different people.
It used to be that some Rustaceans would be aggressive against Zig and that has thankfully died down. We do not need to repeat the same the other way around, so please don't get baited by AI slop.
Also, you don't `catch unreachable` errors when printing to stdout.
This whole article reads like AI slop. I know only a little about Rust and less about Zig, and I have no doubt there are real pros and cons to each. For those of who you love Zig and dislike Rust, no problem! But I got to like halfway through and realized this article was telling me absolutely nothing about anything.
I would love an actual head-to-head comparison between Zig and Rust with real commentary on both the shortcomings and the wins.
Enormous amount of language war slop and like 7 lines of code. Christ. The tragedy wasn’t that LLMs would mimic people but that people would mimic LLMs.
> Rust teaches you ownership like a tough-love therapist. Zig, meanwhile, just shrugs and says, "You break it, you fix it." That's the philosophical divide. Rust assumes you can't be trusted. Zig assumes you're an adult.
Yep, just need programmers to roll up their sleeves and write code without errors. That's worked out great for the whole history of never. And I like Zig, but not this way.
This has a lot of hallmarks of contemporary-LLM-generated prose. I don't think it's bad in and of itself to use LLMs to generate writing, but the prose does come across as kind of repetitive and boring to read.
Anyway I don't see this as a rousing Zig endorsement. The Rust tooling and borrow checker and type system are complex to learn (and contribute to slow compile times which is a genuine downside of Rust), but give you huge benefits in terms of correctness guarantees. And I think people highly underrate the value of writing software that you can guarantee won't fail in certain ways.
I am personally more familiar with Rust than Zig, although I've looked into Zig some. I think that trying approaches to systems languages that are different from the design decisions Rust made is in general a very worthy project. Zig does trade off the amount of memory safety guarantees Rust has in order to have a simpler model of pointers, which is perhaps a reasonable tradeoff in a systems language although I still think the value of the Rust borrow checker is huge. I'm actually more annoyed in Zig by the lower amount of type expressivity compared to Rust - `Result<T, E>` is actually a pretty cool abstraction, and it sucks that you can't easily build this in Zig because of the lack of type level generics support (I'm aware you can do things with comptime to get something similar).
Again, my personal familiarity with Zig is limited and I'm aware the language is still in active development. I think I still prefer the design tradeoffs Rust makes; still, I support the Zig designers (and designers of Nim, Odin, and other novel systems languages) trying out different ideas, and users testing out these languages to build real software.
Is this some kind of language wars engagement farming?
The OP submitted a post earlier titled "Zig Looked Like the Future – Until We Tried Multithreading" from the same blog.
What's going on?
0 - https://news.ycombinator.com/submitted?id=RustSupremacist
1 - https://freedium-mirror.cfd/zig-looked-like-the-future-until...
> engagement farming?
Back in my day we called it trolling.
> from the same blog
It's simply a mirror for Medium, and the articles appear to be from the different authors, posted months apart from each other
> No hidden control flow.
I've really been thinking about this one.
I'm currently designing and implementing an async library and I've been wondering what's better, structured concurrency or explicit scopes.
Explicit scopes allow you to see and think exactly how you want to relate every async task or not. But you have to pass it around, it's more verbose, and you can get mixed up in your scopes.
Structured concurrency handles it automatically, the structure of the code is implicitly the scope of your tasks. Less verbose, can't forget about it, or get it mixed up, but it's magical, you might not even realize it's happening, and understanding mentally what the scope ends up being requires you to understand really well how the structured concurrency implicitly infers your scopes.
I can't decide which is best.
Consider the explicit solution and a layer of sugar for making it implicit from structure, whether it's macros or a DSL or whatever. Abstractions work best when they stack.
Zig or Rust?
Actually Clojure :p
I'm just looking for inspiration elsewhere and I see Zig and Rust as each having chosen the opposite path.
Zig is explicit, pass everything around, the allocator, scopes, etc.
Rust is implicit and heavily structured, allocation, lifetime, scopes is all based on code structure.
> Rust assumes you can't be trusted. Zig assumes you're an adult.
> You can onboard a junior dev to Zig faster than you can explain Rust's Result<T, E> patterns to a senior.
Ahahahahaha. Oh wait, you're serious? Let me laugh even harder!
But seriously this article can't make up its mind. Zig built safety, except it isn't safe because it just trusts you. Zig assumes you're adult and doesn't help you, but also it's easy and anyone can do it!
The contradictions just keep flowing throughout this entire puff piece.
> That's it. No macros. No build.rs. No Cargo screaming about outdated crates. > Deterministic build system that works like clockwork.
Oh, really? Zig doesn't have a build.rs? And why is that? Couldn't possibly just be because it's called build.zig instead, could it? https://ziglang.org/learn/build-system/#installing-artifacts
And what's that? Oh, Zig also has a lazily fetched package manager? And it encourages everyone to use nightly because it's not a stable language yet? Tell me more about how cargo complains too much about outdated crates.
I stopped reading after I saw the bullet point stating Zig doesn't have undefined behavior.
Hahaha that's where I stopped too.
This writing is absolutely too vapid (even as far as AI slop goes), especially for the kind of jabs it makes at Rust.
Zig is not the end solution to all problems, just like neither Rust is. Each is a sweetspot on the spectrum of possible solutions, each with it's own sets of pros and cons that appeal differently to different people.
It used to be that some Rustaceans would be aggressive against Zig and that has thankfully died down. We do not need to repeat the same the other way around, so please don't get baited by AI slop.
Also, you don't `catch unreachable` errors when printing to stdout.
This whole article reads like AI slop. I know only a little about Rust and less about Zig, and I have no doubt there are real pros and cons to each. For those of who you love Zig and dislike Rust, no problem! But I got to like halfway through and realized this article was telling me absolutely nothing about anything.
I would love an actual head-to-head comparison between Zig and Rust with real commentary on both the shortcomings and the wins.
missing from the article is a mention for non-Zig-users how one manages allocators to make "code that doesn't crash" without Rust's borrow checking.
AI slop.
Enormous amount of language war slop and like 7 lines of code. Christ. The tragedy wasn’t that LLMs would mimic people but that people would mimic LLMs.