> You need to know when to free memory, so you explicitly need to reason about it, just like in Rust Obviously! But my point was that that reasoning isn't addi

> You need to know when to free memory, so you explicitly need to reason about it, just like in Rust Obviously! But my point was that that reasoning isn't additive. If an algorithm is complex enough that you have to carefully reason about its object lifetime, then you might have to carefully reason about it even if you're guaranteed to get the lifetime right. Or, rather, sometimes you might, sometimes maybe not, and other times the extra burden of the language is just a chore. > so Zig actually adds cognitive burden, not removes it In that regard -- absolutely, in others, it reduces it. Rust's soundness obviously does some good things -- at a price. The question isn't whether those things work, but if they're worth the price. I'm not saying Rust doesn't give me value for my effort; we just don't know if it's more or less than what Zig gives us. > but on those two specific subjects in is in fact in among the best languages out there. Except Zig takes that to another level. Rust has some brilliant innovations -- like the borrow checker -- but Zig's entire design is a quite revolutionary, and in multiple ways. That's why I find comparisons between it and C to be so misleading. We've never seen anything like it before. > So you keep talking about Rust's cost, but the thing is that you can't really pinpoint what types of cost this is about I don't need to justify why Rust isn't the best approach out there; the onus is on Rust. If we knew which of Rust's approach or Zig's or maybe others altogether worked best, then we wouldn't be trying all of them. We are because we don't know. But assumptions that soundness was the best approach proved wrong in a surprising ways in the past, and a combination of soundness and unsoundness (those "hand wavy" techniques of testing and reviews) are what proved effective. Bot Zig and Rust believe in such a combination, only in different measures. Perhaps in time we'll find out which works better, but you can't say, "fine, sometimes soundness is better and sometimes it's worse, but my mix is better than yours because it has more soundness." Now, I'm not trying to convince you, or anyone, that Zig's approach to correctness works better than Rust's; we simply don't know. What I'm trying to get across is why both approaches are novel and interesting enough that we need to try both. BTW, there's another axis we need to consider. The goal of software correctness from the industry's perspective is not how to write more correct software, but how to write more correct software with the programmers we have. That's why, even though it's possible that the few who can make effective use of Idris might (although maybe not) be able to produce more correct programs than others, few consider Idris as the probably solution to the problem because so few programmers would be able to put it to good use. A language that improves correctness by X around for Y programmers contributes less overall to correctness than a language that improves it by X/2 for 5Y programmers.