I could only see the first few paragraphs, but the writing is giving off a lot of "AI slop" vibes (or perhaps even "human-written slop", let's give the author the benefit of the doubt). So maybe it's no great loss if it's behind a Medium paywall.
Like, what are we doing.
This “article” is flame bait.
This makes it sound like Zig built Rust equivalent safety but its manual memory model suggests otherwise?
And then it wasn't.
And a second thought since the article seems to be flagged now: considering the fan reaction to a post disparaging their favorite language, how is the Rust community different from a religious cult now?
How so?
> considering the fan reaction to a post disparaging their favorite language, how is the Rust community different from a religious cult now?
Believe it or not, not all criticism is created equal. High-quality criticism is consistently well-received from what I've seen. This doesn't seem to get particularly close to that bar.
I've seen other criticisms spawn good discussions and/or a good number of people agreeing, but nothing quite as clearly on point as that off the top of my head.
[0]: https://news.ycombinator.com/item?id=40172033
[1]: https://old.reddit.com/r/rust/comments/1cdqdsi/lessons_learn...
[2]: https://old.reddit.com/r/rust/comments/1cdqdsi/lessons_learn...
As in: we're using a safe language, it's not our fault.
In addition, there's almost always something more going on than using a particular tool and you're generally still going to be responsible for that other stuff anyways. For example, if you're working on something critical and high-integrity you're responsible for the end product functioning as intended no matter how exactly you go about doing that. Using something like SPARK might be a smart way to go about that, but you still need to have processes before using SPARK (e.g., verifying the specifications you're going to implement are what you intend) and processes after using SPARK (e.g., verifying what you implemented is actually what you intended, that the product is indeed working as expected, etc.). If a bug in SPARK results in something unintended happening, you may not be responsible for the faulty proof itself but that's only one failure out of multiple in the entire pipeline - for example, you can't pin a failure to catch the error in testing on SPARK.
> Rust shouted about safety. Zig just built it — without the ceremony, the sermons, or the 15-minute compile times.
Which I interpret as meaning that zig delivers memory safety in a simpler way than rust. But a few paragraphs in, it says:
> 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.
Does this mean that zig's safety depends on trusting the programmer to write correct code? This wouldn't necessarily be a bad thing if zig makes correct code simple to write or has other advantages, but if incorrect code is allowed it makes sense why the compiler can be more permissive and I wouldn't say it's quite delivered the same thing as Rust.
Ok, another thing:
> Zig looks boring. Feels boring. Reads like a C project written by someone who finally went to therapy.
pub fn main() void {
const stdout = std.io.getStdOut().writer();
stdout.print("Hello, World!\n", .{}) catch unreachable;
}
Am I crazy or does this not actually look simpler than
fn main() {
println!("Hello, world!");
}
pub fn main() !void {
std.debug.print("Hello, World!\n", .{});
}
He gave the possible worst example, this article is nonsense.
It has a very weird feeling complaining about build.rs when any semi-serious Zig project comes with a build.zig that's always more complex than any build.rs.
But to address the serious question: We can't have all three of: a simple language, zero-cost abstractions, and memory safety.
Most interpreted language pick simplicity and memory safety, at a runtime cost. Rust picks zero-cost abstractions and memory safety, at an increasingly high language complexity cost. C and Zig choose zero-cost abstractions in a simple language, but as a consequence, there's no language-enforced memory safety.
(Also, having a simple language doesn't mean that any particular piece of code is short. Often, quite the opposite.)
I hate this line of thinking. It doesn't matter if I'm an adult, if the guy before me was a screaming toddler.
"1. Rust Promised Us Heaven. Then Gave Us Paperwork.
Remember the hype? Rust was the "C killer." The messiah of memory safety. The savior of systems programming."
Exactly. That’s what Rust defends us from. It makes breaking things way harder. Rust forces you to think differently, you cannot just do what you want, but that’s it’s selling point. The article focuses mainly on feelings not facts and that’s ok, but I don’t feel exhausted writing Rust. I like that it’s safe and I’m happy to sacrifice some freedom if I get safety in return.
That’s a weird article. Rust wanted to be safe systems language and it is. Where’s the issue? Zig has different goals. That’s ok. What are actually discussing here?
_fizz_buzz_•2mo ago
davidsainez•2mo ago
Simran-B•2mo ago
0-R-1-0-N•2mo ago
hiccuphippo•2mo ago