Arwalk / is on Nostr

I pretend every day that i'm a software engineer and have been very successful at it.

Everyone is wrong. The code for file not found is not 404, but 0x6A82.

PGP Key: https://keys.openpgp.org/vks/v1/by-fingerprint/8E9F8EAC27E963867A6137DB3C63CDD54D3BD0DC
My only worthwhile open source project : https://github.com/Arwalk/zig-protobuf

Last Notes

2024-10-21 14:26:01

- reply

https://media.outerheaven.club/media/709e2e60da2e213bdafd8c02be44ae05639a2b88bdf0ae9cf480a8d8344c2ac3.png

2024-10-18 10:17:44

- reply

> Your argument basically reduces to "some people like C better and would've enjoyed doing what you did in C and done it just as well".
except i was talking about zig? You're being dishonest to right away change the argument and mention C when i never mentionned it.
> Unfortunately, we know that is not the case, and nobody can write correct, complex C code. With Zig not implementing important features Rust has that make writing correct, complex code easier, the only logical assumption is that it also would've not worked out nearly as well.
Dishonest again to keep comparing apples to bananas. Zig, while not being in the same league with rust, is still much superior to C in pretty much every regard about safety.
> If someone wants to prove me wrong, they are welcome to write a complex GPU driver in Zig and see how that goes...
Asking people to spend hundreds of hour to counter your "points" is another case of dishonesty. Especially when i litterally explained to you that what you asked for could be done (but you conveniently ignored it).
> See also: https://chaos.social/@sima/113327356828571637
Yes, what's your point?
Once again, i'm not saying that C should be kept as is in the kernel, or that zig should be used in the kernel. The only thing i said is that you're making assumptions on zig that are plainly false because you don't know enough about it. I agree wholeheartedly on using rust in the kernel.
Keep doing your fantastic work. I have a M1 mac around and have been waiting for the occasion of trying asahi linux since a while.
But just, maybe, avoid talking about things you don't know enough about.

2024-10-18 09:53:18

- reply

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

2024-10-18 09:14:50

- reply

> You can't have a generic vector or map, and just destroy it.
But you can?
https://gist.github.com/Arwalk/69f58af46563dd56e80e4485963a1b56
This test would fail to run if there were any leak, that's what the testing allocator is for.
hasFn is also completely solved at compile time so there is no extra overhead for the list if it has no need to be deinit.
You've been talking about about zig recently, and i'm sorry to be blunt but you've been wrong on a lot of things.
First, zig is to C what rust is to C++. Trying to compare both language when they do not live in the same paradigm (one being imperative, the other object oriented) is simply a bad idea.
You should probably stop fueling the fire and showing that you haven't taken the proper time to explore zig.
I'm not telling you to use zig if you don't want to or that zig is better than rust. Programming languages are tool that fit many uses, and different approaches. If you were more confident in the results of your code using Rust, it's perfectly fine. Just like if someone else could have made it in zig.
But just like i avoid making bold assumptions about rust considering my lack of deep knowledge and experience on it, maybe you should also abstain from doing the same?
Don't feed the trolls, the only answer for the question "why not zig" should have been "because rust fits the needs i have as a developper, and the use case as a tool for what i'm doing".

2024-09-12 08:32:44

- reply

i tried to run https://khoj.dev/ on my nuc, but the fact that it uses the CPU kills everything else that's running on the side.
I don't necessarily want crazy performance, just offloading from the CPU so the rest of my stull can still run.

2024-09-12 06:49:48

- reply

Maybe i should find some other NUC with a GPU to self host that stuff.

2024-09-12 06:44:00

I got a jetson nano, but i realize i don't really have much use for it. I wanted to self-host some AI stuff on it but it's too short on memory for that.

2024-09-12 05:44:42

- reply

have you tried kotlin? It's much more pleasant than java, and doesn't force you in the full OO retardness of it, while keeping compatibility. I discovered it at work a few years before and I appreciate it a lot now.

2024-09-12 05:44:42

- reply

2024-07-31 09:53:58

Note to anyone using heavily docker and wondering why df says your disk is full but du can't find anything big:
docker does not clear volumes even when using `docker system prune -a`.
check your actual docker disk usage with `docker system df` and if local volumes shows a lot of space, run `docker volume prune -a`.
I had 550gb of unused volumes on my work server. :(