I’m aware there is demand for this sort of thing but I’d suggest that almost nobody actually needs it. This strikes me as a feature in search of a problem – especially considering how many of the examples in this document relate to static web assets.
If you’re considering bundling static assets into your binary for a service, you would almost certainly be better served by containerizing your service and copying those assets into the image.
I disagree, one amazing aspect of Go is the static binary that can easily be distributed. I embed templates and other text files in my binaries and it makes the installation so simple and without extra dependencies or steps. Even though I'm a huge proponent of containers I don't think it is needed for things like CLI tools.
When I see all the CLI tools that require NPM / PIP to install hundreds of dependencies I am quite amazed when one requires a single binary. I'm not saying it's a unique feature with Go but that it is nonetheless a feature.
What amazes me is that installing hundreds of dependencies is acceptable, and that modern generations don't get that static compilation goes back to the first compiler, while dynamic compilation only went mainstream around mid-90's.
If you’re considering bundling static assets into your binary for a service, you would almost certainly be better served by containerizing your service and copying those assets into the image.