> But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while
So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust.
You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.
Sure, that makes sense. I agree this is all very subjective, given we don't have the benefit of hindsight for what Zig can accomplish yet.
I think where we disagree is that you believe Zig is as safe as Rust (by making it easier to make other things safer). I don't believe so (my first impression of Zig was Bun repeatedly segfaulting), and I'm just sad that people are choosing the easy route and going for more insecure software, when it finally looked like we made such great progress, with a language people can actually use. I agree with simpler, but there's so many other things that can be changed or removed from Rust, and still leave in lifetimes, or something similar.
> I think where we disagree is that you believe Zig is as safe as Rust
Quite the opposite. Rust is definitely safer in the simple sense that it guarantees more memory safety. But that's very different from saying that Zig is closer to C than to Rust (Zig's memory safety is much closer to Rust's than to C's), and it also doesn't mean that it's easier to write more correct/secure software in Rust (because there are just too many factors).
> and I'm just sad that people are choosing the easy route and going for more insecure software
The jump from "segfaulting" to "insecure" is unjustified, as not all causes of segfaults map to equally exploitable vulnerabilities. Java programs, for example, segfault much less than Rust programs. Does that mean Rust programs are significantly less secure?
> Zig's memory safety is much closer to Rust's than to C's
This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reusing that pointer later even though the union itself may have mutated to a different tag, which results in undetected type punning and potentially wild pointers. The issue of iterators to a collection being invalidated by mutation is quite similar in spirit, and again has nothing to do with the heap per se. Rust prevents these issues across the board. The fact that it also manages to prevent temporal memory unsafety altogether is simply a bonus that essentially comes "for free" given the borrow checking approach.
That's not arguable. Because if we say that memory safety is important because it prevents some common and dangerous vulnerabilities, then Zig clearly prevents the most dangerous of those, while C doesn't.
> you can't prevent a program from inadvertently...
Now you're naming more problems that aren't as high on the list as the ones Zig does prevent (and C doesn't). It's true that type confusion is also rather high on the list, but Zig clearly reduces type confusion much more than C does.
Nobody denies that Rust prevents more issues than Zig via sound guarantees - albeit at what I think is a significant cost, and we can argue, subjectively, over whether those issues are worth that cost or not - but Zig's guarantees are still closer to Rust's than to C's if eliminating very common/dangerous vulnerabilities is what we're judging by.
The underlying issue is that Zig turns out to have no feasible safe subset, just like C - unless you go as far as to declare things like using tagged unions in combination with pointers "unsafe" which is both insanely restrictive and hard to check programmatically. People might complain about having to fight the borrow checker, but they'd complain a whole lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"
> The underlying issue is that Zig turns out to have no feasible safe subset
It does have a safe subset with respect to spatial memory safety, which is the more important kind of memory safety if what we judge by is dangerous vulnerabilities.
> People might complain about having to fight the borrow checker, but they would complain a lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"
I don't know how you can say that this is an objectively-supported claim given Rust's poor adoption at its age.
So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust.
You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.