News for hackers. Stuff that matters.
Re:ZapFast: A fast, native WhatsApp client in Rust and egui by rtpg on Sunday November 08, 2026 @02:36AM (#50411177)
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?

> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time

I think what's happening in the second one is that because you're using the native OS toolkits a bunch of stuff is shared, whereas with these "self-contained" "native"-y apps you end up having to load up the whole world and aren't sharing things with everything else

I'd love to be proven wrong but I feel like if you use e.g. Qt you're gonna have to hold onto a bunch of stuff that you wouldn't if you were "just" using OS-native stuff (though maybe that gets shared if you're using the exact same version? Is there something that can be done in this space?)

Re:ZapFast: A fast, native WhatsApp client in Rust and egui by elendilm on Sunday November 08, 2026 @02:47AM (#50411223)
With Qt, on my KDE Linux, a simple app usually stays well below 60 to 100 MB.
Re:ZapFast: A fast, native WhatsApp client in Rust and egui by saghm on Sunday November 08, 2026 @09:41AM (#50413759)
As an additional data point, I recently vibed an egui wrapper around a library I wrote for mod management for a game, and testing it out now, it idles at 92 MB. This implies to me that at least half of the overhead is probably not from the gui framework, but I also don't know how much effort they spent trying to optimize it; I didn't try to optimize my vibed GUI app at all, but I did hand-write the library that it uses for file management, state tracking, etc., and I tend to go out of my way to try to avoid unnecessary allocation in my Rust code. I don't know how much of the memory usage is essentially required overhead or from other dependencies for non-GUI parts of the app, but my instinct is that there's probably a bit of optimization that can be done. I don't think it's crazy for them not to have spent the effort on trying to do that yet though (or potentially even at all, if it's efficient enough for their own personal use).