4 ms·
It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer.
by audunw 6y ago
It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators.
Zig will probably never be as safe as a GCed language or Rust in this regard. But that's because it would go against other core design goals.
I feel like the future of non-GC languages is Zig as better C (dead simple and explicit language), and Rust as better C++ (complex language with more memory management facilities, etc).
The choice of languages was a bit odd. But I think Go is still in C's territory when it comes to being simple and explicit. Memory management (GC/not-GC) isn't necessarily the most important distinction in programming languages.
- tialaramex 6y agoWhat would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ? I don't care about that in a Python program, but I can't see why I would accept it from something that's supposed to replace C. I also think you're imagining a lot of hard work during execution in Rust that just isn't there, most of the tricky stuff happens at compile time. If you can prove you really don't need the safety that does have runtime implications, you can choose not to have it, but of course you probably don't have proof, just the same gut instinct that usually gets us into trouble in other languages.