Arwalk on Nostr: > I don't want to have to manually write a deinit function for a complex object with ...

> I don't want to have to manually write a deinit function for a complex object with 20 members

And i prefer to avoid things happening too much magically under my code. Writing a deinit function for a custom object is a sensible thing to do. And it would be possible to make a generic deinit method actually (just make the compiler iterate over each member, if(hasFn(T, "deinit")) item.deinit()). The reason because it's not done by default in the std lib is about giving the choice of control about how and when something is freed. Your need might not be the same need for everyone.

> On top of that, just because you *can* do that with Zig doesn't mean the language encourages it.

Wrong, deinit has been explicitely used as the method when freeing a strutcure, and is an approach that is in use in every library you'll find, including std.

> Then there's the fact that `defer` doesn't really cut it. It only works if you allocate an object and you *always* free it after. With proper RAII as in Rust, I can have code paths that consume or otherwise do something useful with the object and don't free it locally, and know that all the *other* code paths (only) will call Drop, and the compiler takes care of that. Zig has `errdefer` but that's just a special-case band-aid to handle the specific case of "keep on success, free on error" which covers a bunch of use cases, but not all of them. And you still need to remember to use it, and if you don't the only way to find out you missed it is with a leak checker, and then if the leak only happens on error paths then you need a way to trigger those in your unit tests...

See, once again, comparing apple to bananas. RAII is irrelevant to a purely imperative language. Zig expects you to manage your memory manually, so anything about you said is bogus: you're just trying to be right for the sake of being right.

> it definitely isn't the right language to bring to the Linux kernel because it doesn't solve the problems we're trying to solve.

Opinions + who is "we" and do you believe your opinion is the same as everyone?

> I wrote a whole GPU driver and I had practically zero memory leaks (except for a reference loop once), practically zero memory errors (just some dumb stuff that was an instant crash early on in unsafe code because I was writing a memory allocator for GPU memory). The whole thing relies on all the Rust magic to keep things clean and safe and reliable.

I know what you did. It's really great work. It's a nice showcase of rust, and i never told you that i was against rust. I'm just telling you don't really know what you're talking about, are not trying to actively learn zig, and just don't like how zig works because you prefer rust. The last 2 points are perfectly fine, the first is not, and that's what you should avoid.

> And from everything I've seen about Zig, that just would have never worked nearly as well, nor made writing the driver nearly as enjoyable, especially the part where once the core code works everything works and I don't have to debug any leaks or crashes.

And some people would have enjoyed doing that in zig, and pretending that nobody could have done as well is pompous at worst.