I see some of the pro-Zig folks arguing that "I don't want the compiler doing magic behind my back".

The compiler is there to help you. That's its job! Once you learn to trust the compiler, then you don't have to worry about getting cleanup code right ever again.

Is the compiler magically invoking drop() sometimes a problem? Yes, but that's the minority of cases, and there are solutions to that. I even worked on some of them (Arc::drop() integration with kernel lockdep to catch potential locking issues with refcounted objects across all invoked drop sites, not just those that actually drop the ref count to zero). The point is that it makes a lot more sense to work on solving these corner cases, than to just throw away the entire mechanism and have fallible humans in charge of writing more complex code as a result.

Trust the compiler, and when it does the wrong thing, find a good, general solution so it doesn't any more. Rust is actively working on solving some of these issues upstream too, and I find that a lot more positive than just saying "we won't even try, just write cleanup code manually".

@lina if you're putting all your trust in the compiler to keep you safe, wouldn't that lead to being taken down the path of bad habits? Surely it's better to learn how to keep your own code safe and not depend all your trust into a compiler?

The take away, for me, is this; if you can't write clean code and need something else to do it for you, learn. Learning makes you better, and being better makes you want to learn more.

@meatlotion @lina This is an insane statement. I have fixed multiple people's code, from extremely smart and competent people, by enabling GCC/Clang compiler warnings to catch *very* easy mistakes (i.e. `if (x > 15 && x < 0) {}`).

The point of a compiler, and abstractions in general, is to allow you to work on a higher semantic level *without* needing to care about the inner workings of it 99% of the time, which allows you to focus on the things that matter.

@Girgias @lina well I'm no dev, I'm practically nothing more than a script kiddie at best, but what you say doesn't seem right to me. If I want to write sloppy code, and it breaks my system, that's on me. If I want to learn how to code cleanly and correctly, so I don't break my system, that's also on me.

Sounds like a lot of excuses for lazy code to me, from my uneducated way of thinking.

If this isn't how it is, then sorry, but that's how it comes across to me.

@meatlotion @lina Then maybe "trust" people with more experience about their opinion.

This sort of thinking is why other engineering disciplines think software is a joke. Eh why should I use a harness when going up on a scaffolding, just don't fall, if you do, that is a skill issue.

Eh let me manually do all of those complicated force calculations for this tunnel I'm building, if I mess up the only consequence is for it to collapse and kill a couple thousand people.