5 comments
I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
> Zig is well on its way to a third path with potentially the same level of safety
No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.
That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.
No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.
That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.
The logic is the same as arguing that people still die while wearing seatbelts, or cut their hands while having protective gloves, thus they are worthless.
It's a false economy. Mediocre isn't good enough. The fact that mediocre is better than nothing isn't relevant when so very much better was easy.
We're talking about thermionic valves versus transistors in terms of how dramatically worse this option is than actually doing the Right Thing™.
The valve computers weren't relegated to a few specialist tasks, or seen as a particular trade-off that's no longer applicable for some applications, they were just swept aside, because they were obsolete. The memory unsafe languages, likewise, should just go away.
We're talking about thermionic valves versus transistors in terms of how dramatically worse this option is than actually doing the Right Thing™.
The valve computers weren't relegated to a few specialist tasks, or seen as a particular trade-off that's no longer applicable for some applications, they were just swept aside, because they were obsolete. The memory unsafe languages, likewise, should just go away.
Yes, unfortunately just like those valve computers, progress only comes at the expense of a complete change of generation, where there aren't enough people propagating outdated concepts.
If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to.