I have a new pet project.

https://code.rosaelefanten.org/rssfs

Don't look at the WinFsp implementation yet. :-))
(It lacks... everything.)

Cool. I might have to finally get around to learning Go.

Please do. Because my Go sucks and I need contributions. ;-)

(11-05-2020, 04:07 PM)jkl Wrote: Please do. Because my Go sucks and I need contributions. ;-)

Y'know, I might have picked a good time to take another stab at learning Go. It looks like they're making progress on the executable size issue that annoyed the hell out of minimalist me when I tried it back it the early days:

https://twitter.com/bradfitz/status/1256348714198654976

Technically, Go still has massive binaries which can only be improved to a certain extent (static linking, hooray). I guess it could be a good exercise to strip the binaries down to their lowest size, as it is in the Delphi/Lazarus world.

I know. As long as Go has garbage collection, a scheduler for goroutines, etc. it will have a hefty runtime compared to good old C. There's no free lunch.

I like static linking too, and I think Go's binaries aren't so bad when you compare them to the whole executable + shared libraries set that you would get with a dynamically-linked equivalent. (I hear gccgo can create smaller binaries but also that they're slower. Haven't tried it myself.)

upx also looked interesting when I started reading about it today, and it does dramatically reduce the size of the binaries. But I don't think I like the slower startup due to the decompression step. As far as I can tell, the main benefit of upx is saving disk space but for me the whole point of smaller binaries is faster launches and less thrashing thanks to smaller working sets. I'm not sure upx helps with either of those. But I only found about it today while reading up on what people have been saying about the size problem.

In my opinion, UPX makes no sense, as the reason for the main advantage of smaller binaries (the overhead) is basically even worse with it.