This > You still end up chasing SIGSEGVs. and the memory leak part are interesting. The think is if you do very low level stuff with rust, like embedding pro

This > You still end up chasing SIGSEGVs. and the memory leak part are interesting. The think is if you do very low level stuff with rust, like embedding programming are interacting a lot with C interfaces (or providing them) this is true without question. Similar if you rewrite some of the low level micro optimized parts of a async scheduler like tokio. As a PSA the rust type system and borrow checker even helps with unsafe code as it doesn't remove this checks, just gives you additional tools do to stuff which can undermine them, but (the PSA part) at the same time you have to make sure you uphold the rust safety constraints and memory model (which isn't fully specified yet) which can sometimes mean some things which are fine in C are not fine in rust even if you can do them with unsafe code! But for a lot of the daily work of a lot of rust project you don't really run into segfaults (if you don't do premature micro optimizations or write in a very non rusty stile of using a ton of unnecessary unsafe). Similar memory leakage is limited to stuff like circular Arc/Rc or global collections where you put stuff in but don't remove it. But due to shared long lived ownership (e.g. Rc) being very explicit it happens less often in my experience compared to GCed languages. Anyway that is if you stay in rust, especially safe rust. So I'm not surprised that someone who considers Zig as tooling doesn't have this experience as they are likely having a lot of tasks which involve aspects where rusts type system runs into limitations of how it can help you.