←back to thread

200 points jorangreef | 1 comments | | HN request time: 0.201s | source
Show context
tobz1000 ◴[] No.24293284[source]
Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts.

Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implications for IDE complexity and performance. I imagine the performance side of this could be (maybe is?) mitigated by limiting recursion depth/loop counts for compile-time work.

I'm not particularly interested in taking on a language with manual memory management and the responsibilities it entails, but I would love to have access to Zig's compile-time capabilities, if it were available with some more memory safety.

replies(2): >>24293329 #>>24294235 #
pron ◴[] No.24293329[source]
Zig gives you memory safety (or, rather, will ultimately do that), but it does so in a way that's different from both languages with garbage collection (whether tracing or reference-counting) or with sound type-system guarantees a-la Rust. It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production. You lose soundness, but we don't have sound guarantees for functional correctness, anyway, and given that Zig makes testing very easy, it's unclear whether a particular approach dominates the other in terms of correctness.
replies(6): >>24293512 #>>24293563 #>>24293661 #>>24296835 #>>24298380 #>>24299940 #
1. azakai ◴[] No.24293661[source]
My understanding is that Zig goes further than that. In particular it just added a safe allocator suitable for production,

https://github.com/ziglang/zig/pull/5998

edit: For more details, see

https://ziglang.org/#Performance-and-Safety-Choose-Two