> 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.

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.

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.

> 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.

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...

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.