and for a summary - space usage is one of the reasons for me not using it, but there are more reasons. and many of these can be solved if flatpak uses some for of compression (squashfs/dwarfs) and smartly mount the required flatpak archives. This is one the best things that snap does, but they do many things wrong the other way.
Recently I have been using language specific package managers more - cargo (and cargo binstall) to get most of rust stuff. And since I like new stuff, I happen to have quiet a few (~20) packages from it. binstall allows to fetch binary releases. Only major problem with it is that cargo has limitations in it’s pacakaging, and effectively only /bin parts of package is installed
I am using soar now for appimages and some other binary packages (go and rust) (recently got like 10 packages from it, and will update my page too), but if a package is on cargo, and soar, I prefer the cargo one (no strong reason for it).
I recently wrote about this in my setup post (which is not yet complete) so for a more detailed answer - https://sga.codeberg.page/setup.html#loc-13
and for a summary - space usage is one of the reasons for me not using it, but there are more reasons. and many of these can be solved if flatpak uses some for of compression (squashfs/dwarfs) and smartly mount the required flatpak archives. This is one the best things that snap does, but they do many things wrong the other way.
The official AppImage runtime has been static (no longer depends on any libfuse) and built with fuse3 since 3 years ago. Only electron builder remains with this nonsense of using the old runtime.
Also DWARFS AppImages that also do not need FUSE at all to run.
I am using soar now for appimages and some other binary packages (go and rust) (recently got like 10 packages from it, and will update my page too), but if a package is on cargo, and soar, I prefer the cargo one (no strong reason for it).