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.

@meatlotion @lina Because if the focus is on writing "clean code" and need something else to do it for you, then even writing C or Zig is too high of an abstraction layer, and you should be writing assembly directly.

@Girgias @lina you can write clean code in BASIC, and you can write lazy code in BASIC.

Lazy code and clean code is a choice.

@meatlotion @Girgias You can write correct code in C and Zig and Rust, it just happens to be easier to do it and do it correctly in Rust.

Conversely, correct code is *less* clean in C than in Rust, because the language requires you to micro-manage resources. There is simply *no* way to write correct C code that is as clean as correct Rust code.

@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 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.

@meatlotion @lina And the thing is, in software there is no consequence for doing shit like this, my partner in civil engineering can be held liable just for a *verbal* suggestion or acknowledgement of a bad idea if the consequences of it are dramatic.

@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.

@meatlotion @Girgias @lina By that analogy, do you expect your chef to manually sift through the grain to pick out small rocks that are mixed in and then mill it into flour with a hand mill rather than use a sieve and a water or electricity powered mill? Because I haven't seen any professional chefs particularly passionate about picking rocks from a sack of grain, no matter how artisanal and gorgeous the cakes they bake are.

Similarly to how you'd use a sieve and an electric mill these days, Rust tries to shift the path of least resistance to something that is correct by default so that you can focus your energy on what you *actually* want to be making (the cake).

@meatlotion @Girgias @lina
You come across as someone that doesn't have enough experience and background knowledge to understand what problem this is trying to solve.

You're a cook that doesn't yet know what a good pie is supposed to taste like.

@meatlotion @Girgias You're basically arguing against computers and that we should just go back to the abacus at this point, because why get paid all the big bucks doing math if you can be lazy and just plug it into a spreadsheet?

Better tools don't make people lazier, they make them more productive.

@lina i'm pretty sure they're just trolling
@lina
@meatlotion @Girgias and not only more productive, but safer! To me, the Rust compiler is like a SawStop on a table saw. Sure, you might think "oh just be careful" but experienced woodworkers missing fingers proves that humans just being more careful isn't enough. The compiler is never tired, or distracted, or learning- it gets it right every time.
@lina @meatlotion @Girgias You're still not going to be reckless with a SawStop-- as I understand it, when it activates, you have to replace the blade and part of the SawStop, which costs money, so you don't want to be doing that every day. And there are injuries you can get from a table saw that the SawStop can't protect you from. Similarly, I still write tests for my Rust code, I still get my Rust code reviewed, etc. The compiler doesn't protect you from logic bugs!
@lina @meatlotion @Girgias Last point: it's *because* I take pride in the quality of the software I produce that I want to use Rust to get as much help as I can.
@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.

@meatlotion @lina @Girgias This is like saying that (physical) engineers shouldn't use calculators because it makes them lazy and bad at arithmetic. Their job is not to do arithmetic well, it's to design complex systems thoughtfully and systematically, and they have spent decades developing tools and practices to account for human error because they KNOW that humans make all sorts of simple mistakes, even the humans who are the best, brightest, most motivated and dedicated in their field.
@meatlotion @lina @Girgias one of "biggest buck" programming languages are garbage collected, so this is literally nonsense. Writing code in Rust, at least initially, is not that much easier than other system languages. It makes it easier to maintain the codebase in the long run though.

@meatlotion @lina @Girgias

If anything a C compiler allows you to be much more lazy than the Rust compiler. It will accept programs that are blatantly incorrect and you can write code that accidentally relies on this. The Rust compiler, on the other hand will force you to do things correctly.

A meta-point: I've been programming for 15/16 years are this point and one big lesson I've learned is that programming is hard and humans are fallible(as evident by all the CVEs we produce every year). Embracing your fallibility and finding tools to help you avoid it is the only way forward. This isn't laziness, it's recognising your humanity.

@meatlotion @lina @Girgias lazy at catching repetitive universal memory bugs means you spend all your mental energy focusing on actually buiding the thing you wanted to build in the first place??? i switched my c++ project to rust after 2 MONTHS STRAIGHT of debugging memory errors and my GOD was that the right decision... haven't had a memory error from my own code in years
@meatlotion @lina @Girgias is using a circular saw with a guard laziness? The attitude you're spouting is the same one I've seen of younger people in the crafts that refuse to use safety equipment that is there to avoid being maimed or killed with empirical evidence they work. Is it lazy for a machine to require two buttons separated by arms length to be pressed by an operator in such a way that both arms are assured to be away from the work area with the arm munching piston?

@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.

@Girgias @meatlotion @lina As the editor for C reading this conversation from this meat person hurt my brain, so much I'm gonna hand out the rare block. Confidently ignorant AND wrong is not just a talent, but a skill and with the performance this person put on that's a 10/10 on the "I never wanna hear from this person ever again".

@meatlotion

@lina @Girgias

If you are only writing sloppy code that breaks on ONLY your system fine. However almost all code is written to be run on someone else's system and then you have a moral imperative to write code that doesn't break.