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.

@lina @Girgias all I am reading between the lines is, I want to be lazy at coding, but still want to get paid the big bucks, which language can I use that will do all the work for me so I can still get paid?

Might as well use ChatGPT at this point lol.

I am uneducated, I'm no dev, people should have more pride in the work they do, not the work something does for them.

@meatlotion @lina Your job is not to have pride, your job is to provide value to the people that pay you for the software you write.

And they care that your code doesn't have any bugs nor vulnerabilities which might cost the business millions of [insert favourite currency].

You can be proud of your craft, but at the end of the day, no-one cares how you feel about your code and that your code is more "pure" and doesn't use a pesky compiler to make your code safe.

@Girgias @lina I think you're absolutely wrong, in any job you put your hand to, if it's worth doing, it's worth doing well. Pride in your own work shows you will do the best you always can. If you have no pride in your work, you shouldn't be doing that job. Period.

A chef who has no pride in their work makes crappy pies, a chef that has pride in their work, will create the best looking pie they can, a masterpiece.

Chew on that for a while.

I restate my original point, don't be a lazy programmer. If it's worth doing, it's worth doing well.