If you're concerned about compile time -- Go does a pretty reasonable job of caching (including caching unit test results). If you're working on a Python project with a large number of unit tests, because Python is so slow to execute anything, and the go build and test tools are quite fast, it wouldn't be that surprising if it was actually faster to compile and run the test suite in Go vs running the test suite in Python -- particularly for incremental work where you make a change in one library and rerun the impacted tests.
If you're concerned more about the workflow of needing an additional compile step, go has `go run script.go` which lets you use go like a scripting language, assuming you're in an environment with the go toolchain installed.
Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.
My point being to the users of the products we create, software licensing is not what they are thinking about.
>Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
pkg.go.dev and gopls also automate away most of the "exploration" I would be doing in Python REPL.