On the Zig vs. Rust debate, people like to focus on memory safety, but Rust's RAII is just as important to writing clean, maintainable code.

There is something truly magical about seeing my GPU driver cleaning up dozens of nested GPU and host objects when the GPU job completes. Always exactly then, never too early, never too late, never leaking anything. That's all thanks to RAII and automatic Drop calls.

defer foo.deinit() really doesn't cut it. You have to explicitly write it, and it only works if all code paths free the object at the end. errdefer is just a special case, and then the only way to know if you forgot it is by testing with a leak checker. And then the deinit function has to manually deinit all child objects.

All this stuff is just done automatically in Rust. Most of my types don't even implement Drop, or only do something trivial there, because the compiler recursively dropping objects is 99% of the work.

It's knowing the compiler is on your side and taking care of all this that makes it magical. 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.

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 @Girgias You might want to trust experienced developers who have actually spent time with multiple languages and understand what works and what doesn't, and the limitations of human fallibility...

@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 @Girgias are you aware that if you don't know enough to participate meaningfully in a discussion you can simply…not do so?
@tedmielczarek @lina @Girgias but the other participants clearly don't know enough either, only I am able to say it 🤣
@meatlotion @lina @Girgias you're arguing with a woman that is writing Linux kernel drivers in Rust and your entire argument is "well I just think this other thing" so maybe consider that you're just uninformed and wrong.

@tedmielczarek @lina @Girgias oh believe me I do consider I'm wrong all the time, just in this instance so far, you haven't given me reason to show me I am.

I appreciate you doing all that you do in the Linux kernel, I certainly wouldn't have the first idea about even a fraction of a percent of what you do, but if you have no pride in your work, why the hell are you doing it?

Go do something you actually have pride in, bake a cake, mow the lawn, make a sculpture... but if you get no pride in coding, don't do it.

The mind boggles.

@meatlotion @tedmielczarek @lina You are making some wild assumptions, do you not think I have pride in maintaining PHP and fixing the bugs in it?

But I don't have pride of writing C code, the thing I care about it is the *end* product, you seem to limit the thing one should care about the *process*.

I would rather not need to spend my time on 20y old+ bugs because someone forgot to check a NULL pointer dereferencement.

@Girgias @tedmielczarek @lina perhaps I have been looking at this from the wrong angle. knowing a little more context, you are not referring to your own code that is lazy, but trying to fix other people's lazy code.

That is no small feat, and once again I want to reiterate that I appreciate what you're doing. Perhaps even more so from understanding this tidbit of a nugget.

That doesn't take away from the fact that doing a job without pride means the job won't get done as well as it would if it was done with pride, so in that respect, my statement/pondering/musing still stands - if you have no pride in what you do, go do something you _do_ have pride in.

You owe it to yourself, at the very least.

@Girgias @tedmielczarek @lina also, the *process* is just as important as the *end* as well, if all you care about is finishing the product, you will bodge it all together until it does what you want, but if you actually care about the process, then you will make it to the end happier, better, and with more pride.

When driving a car from A to B, do you care enough not to mow down pedestrians in the way? Do you have pride enough to make good the *process* too, or just the *end*?

I rest my case.

@meatlotion @tedmielczarek @lina Do you drive your car without any of the safety feature built into it? Do you not use ABS, power steering, collision detection, and only drive manual?

THIS is the correct comparison of what you are *claiming* developers should do and the reality. I am using the *safety* feature that the language and a compiler provides me to not put other people in danger.

Your case is non-existent. You would prefer someone to *maybe* mow down a pedestrian than being unable to.

@Girgias @tedmielczarek @lina my car has no ABS, power steering or collision detection, and it is manual only. I drive a 1985 Ford Capri =)

I do appreciate your analogy though, and it makes complete sense to me too, so thank you for that. However, the safety to not kill someone is slightly different to what we're talking about, although if this were in the kernel and that was powering some ciritical machine in a hospital keeping someone alive, it would be better to be safe than have an unknown.