[menthe]

Meh, typical overblown “take” ihmo.

> All this stuff is just done automatically in Rust. If you have to write out the code by yourself, that's more work, and a huge chance for bugs. The compiler is doing some very complex tracking to figure out what to drop when and where. You'd have to do that all in your head correctly without its help.

What prevents anyone from dedicating a Zig memory allocator to the job (and all of its subtasks), and simply freeing the entire allocator at the end of the job? No baby-sitting needed.

Or if the mindset is really to be assisted, because “very complex” and too “much work”, may as well use a garbage collected language.

> It's knowing the compiler is on your side and taking care of all this that makes it magical.

Until you got used to it, and trusted it so much, and it suddenly misses something - either after a compiler update, or after some unsupported code introduced, and that shit takes down prod on a Friday. I’m not going to take the chance, thank you, I can call free() and valgrind.

[TUSF]

> What prevents anyone from dedicating a Zig memory allocator to the job (and all of its subtasks), and simply freeing the entire allocator at the end of the job? No baby-sitting needed.

Given the whole ecosystem is built around the Allocator interface, it's entirely feasible for the consumer of a library to pass in a Garbage Collecting allocator, and let it do the job of deciding what gets dropped or not.

Downside is that this is all at runtime, and you don't get the compile-time memory management that Rust has.

[rofrol]

https://kristoff.it/blog/raii-rust-linux/