4 ms·

It looks like Zig requires manual memory magagement, right? That seems like a pretty big downside compared to GC or the Rust approach.

linkdd 6y ago
That's because the Zig approach is "no hidden control flow". Everything in Zig is explicit, this is not a downside, this is a feature of the language. Choose the tool that best fits your needs.
- cageface 6y ago
  That's fair but that does mean that I wouldn't consider it unless I really needed that kind of control. That's a niche few devs need to worry about.
  - linkdd 6y ago
    One advantage of that kind of control is that your code does not depend of the implementation of any abstraction (except the operating system if any?) since everything is written "in stone". I also think it makes a great learning tool, mainly to understand: - how a GC or memory management is/should be implemented - what pain points they solve (or: why they are important) When you don't have to think about the abstractions but only your code, it prevents the student from being confused about what happens when. But I would not use it in production, just like you said, because in production, I want to maintain as little code as possible, and delegate the complexity to other better tools/people.
  - mtzet 6y ago
    Well the choices so far seems to be manual memory allocation, RAII or GC. The complexity of C++/Rust indicates that RAII is certainly not a panacea either. GC offers distinct trade-offs as well. Zig takes a stab at the problem by trying to make manual memory management more ergonomic. I've been pleasantly surprised at how easy I found it to do tasks in Zig I would otherwise have used a scripting language like Python for. If go's fast GC is taking a stab at C's territory, then I think Zig is taking a stab at the managed runtime's territory. Ultimately the judge is still out.
diragon 6y ago
True. That is however countered by a vastly simpler language. Language support for deferred cleanups[0] helps a bit. Also the GeneralPurposeAllocator[1] contains memory safety debugging features that make analyzing such bugs bit nicer. IMHO it's a significant net gain over something like Rust because of the simplicity for most of the problems out there. I got 99 problems but needing absolute memory safety ain't one. [0] https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer [1] https://ziglang.org/learn/samples/#memory-leak-detection https://ziglang.org/learn/samples/#memory-leak-detection

linkdd 6y ago

That's because the Zig approach is "no hidden control flow". Everything in Zig is explicit, this is not a downside, this is a feature of the language. Choose the tool that best fits your needs.

cageface 6y ago
That's fair but that does mean that I wouldn't consider it unless I really needed that kind of control. That's a niche few devs need to worry about.
- linkdd 6y ago
  One advantage of that kind of control is that your code does not depend of the implementation of any abstraction (except the operating system if any?) since everything is written "in stone". I also think it makes a great learning tool, mainly to understand: - how a GC or memory management is/should be implemented - what pain points they solve (or: why they are important) When you don't have to think about the abstractions but only your code, it prevents the student from being confused about what happens when. But I would not use it in production, just like you said, because in production, I want to maintain as little code as possible, and delegate the complexity to other better tools/people.
- mtzet 6y ago
  Well the choices so far seems to be manual memory allocation, RAII or GC. The complexity of C++/Rust indicates that RAII is certainly not a panacea either. GC offers distinct trade-offs as well. Zig takes a stab at the problem by trying to make manual memory management more ergonomic. I've been pleasantly surprised at how easy I found it to do tasks in Zig I would otherwise have used a scripting language like Python for. If go's fast GC is taking a stab at C's territory, then I think Zig is taking a stab at the managed runtime's territory. Ultimately the judge is still out.

diragon 6y ago

True. That is however countered by a vastly simpler language. Language support for deferred cleanups[0] helps a bit. Also the GeneralPurposeAllocator[1] contains memory safety debugging features that make analyzing such bugs bit nicer. IMHO it's a significant net gain over something like Rust because of the simplicity for most of the problems out there. I got 99 problems but needing absolute memory safety ain't one. [0] https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer [1] https://ziglang.org/learn/samples/#memory-leak-detection https://ziglang.org/learn/samples/#memory-leak-detection