Thanks for not answering I guess

That’s the toxicity that people talk about when they complain about the rust-religion believers.

Thank you for the kind feedback 👍

I had no idea that this was all so recent. Zig is similar to what I'd been thinking about for several years, removing the last few artificial obstacles to optimization.

Totally bizarre interview. Dude doing straight digressions on his high school courses wth

nah man that was Ginger Bill announcing a new beer.

It’s a weird interview. Andrew is trying to best to be a polite guest but I do believe one can hear the “WTAF” rummaging in the back of his head.

Leaking memory is not necessarily unsafe. Garbage collection is related to memory safety in the sense that you can't dereference dangling pointers.

Hard disagree here. In an ICBM and most other embedded applications, consistency is the most important factor above all else. That's why garbage collection is an absolute no-go, because it has non-deterministic runtime characteristics. If the guidance computer needs to produce a course correction every millisecond (for example), then it needs to hit that target without fault or deviation. Evidence of this is redundancy. Even in the confined environment of an ICBM, there are redundant compute systems. If performance above all else was the goal, then the redundant compute platform would instead be used to tackle the task in parallel. This is why embedded is largely the domain of C and ASM, its runtime characteristics are very well established and controllable. Go, Python, C#, etc. will never be successful in embedded simply because it is not known how it will perform. Zig fits in the same category as C (arguably better since allocation control is easier) in this context. Rust is different in that its abstractions add a lot of separation between what an author writes and what actually gets run on the hardware. Runtime performance is exactly as repeatable as C, Zig, and ASM though.

@@zactron1997 When you have an extremely restricted environment where ever single CPU cycle counts and you at the same time have an almost 100% predictable execution plan, memory deallocation becomes secondary. Deallocating memory uses CPU cycles, CPU cycles are expensive (in every way) and memory is cheap (in every way). Therefor you can build the system, let it leak memory, measure how much memory it will ever maximally need including the leak, and then have your hardware manufacture double that memory so that it will never run out. I came across this implementation many years ago in a talk from a NASA engineer who had previously worked in weapons manufacturing. I can't find that talk right now, but I randomly came across a mention of a few days ago in this video: kzbin.info/www/bejne/iouYkmadeKiNj9Esi=oMUclYZfRE0x9uE7&t=740 I have no idea if they still do it today, but it absolutely makes sense in certain scenarios and it is worth keeping in mind as a possible solution.

@@phrsngx5675 No not at all, and with the amount of memory we have available in modern PCs we could leak quite a lot before it becomes an actual problem. Probably shouldn't though 🙂