Here are some more options you could consider. 1. Do what busybox does: put them all into separate packages, link them all into one monster executable, switching on os.Args[0] to decide which main function to run. Then add lots of links or symlinks to the same program so it can be executed under multiple names.
To make this more modular you could build the packages as go plugins, although there are a lot of limitations to beware of: https://www.reddit.com/r/golang/comments/b6h8qq/is_anyone_actually_using_go_plugins/ejkxd2k/?utm_source=reddit&utm_medium=web2x&context=3 2. Use one of several Go interpreters out there. However I'd expect execution speed to be less than python, which has had years of optimisation. 3. There's tinygo - although it doesn't support Windows AFAIK, maybe the Linux binaries could run under WSL. It's a substantial subset of go, and by default achieves binaries less than 0.2MB. If you turn on a bunch of options (such as disabling goroutines and the garbage collector) and avoid "fmt" you can get really tiny standalone binaries: https://tinygo.org/docs/guides/optimizing-binaries/ brian@builder:~$ cat hello1.go package main import "fmt" func main() { fmt.Println("Hello, world!") } brian@builder:~$ cat hello2.go package main //import "fmt" func main() { println("Hello, world!") } brian@builder:~$ tinygo build -o hello1 hello1.go brian@builder:~$ tinygo build -o hello2 -no-debug -panic=trap -scheduler=none -gc=leaking hello2.go brian@builder:~$ ls -l hello1 hello2 -rwxrwxr-x 1 brian brian 171408 Jan 30 08:05 hello1 -rwxrwxr-x 1 brian brian 7800 Jan 30 08:05 hello2 On Sunday, 29 January 2023 at 20:26:51 UTC bobj...@gmail.com wrote: > I'm glad to see this issue getting some discussion. I have 100+ smallish > utility programs written in Go, and each one consumes about 1.5 MB (precise > average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go > runtime. Sadly, I mainly use Windows, and there seems to be no way to use > linked libraries in Go for Windows. > > My solution has been to rewrite many of my smallish Go programs in Python > (except those that really need Go's speed) -- 10K each vs. 1.5M each disk > storage. For these manually invoked utilities, the speed difference is > often not noticeable. And the number of source lines and overall program > complexity is reduced by roughly 30%. (Added benefit: the Python programs > are always properly indented, even without a "pyfmt" program :-) > > I *am* a Go fan, and I understand that Go's mission is for writing big > server programs, but it's too bad that the size of a small Go program > executable is *many* times larger than a small C program. > On Sunday, January 29, 2023 at 9:49:17 AM UTC-8 jlfo...@berkeley.edu > wrote: > >> The discussion of SSD wear and tear is going way off my original >> question. I'm sorry I even mentioned it. >> Can we drop it? >> >> I'm still interested in the answer to the original question, which we've >> made some progress in answering. >> As of now the answer is yes, subject to some permission and performance >> problems. I hope the experts >> can shed some light on these. >> >> Cordially, >> Jon Forrest >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f887c373-0827-4fd3-9135-79b56857f423n%40googlegroups.com.
