Comment 1:

I'd rather not build these kind of things into the language.
maybe we can figure out a way for the go tool to do some
kind of asset packing, but I'm not sure about that either.

Labels changed: added languagechange.

Comment 2:

I'm not sure if that's a good/plausible approach either, just trying to get a
conversation started, since I don't seem to be the only one that would love to add some
resources to the binary more conveniently.

Comment 3:

I don't like this approach (cf. built-in compiler magic function).

Comment 4:

What's "magic" with this approach?
The only difference is that the compiler would assign the binary contents of a file to
some variable instead of parsing code and then doing exactly the same with a constant.
It would just expand on concepts that go already uses for specific architectures (e.g.
"_<arch>.go").

Comment 5:

FYI, the _$GOARCH.go naming convention is provided by the go tool.
the core Go language doesn't know that (in fact, the gc compiler
won't complain if you feed a valid Go program with a .html filename
suffix to it)

Comment 6:

@4: 1) A built-in compiler magic function is a function which cannot be written in the
by-the-compiler-accepted-language per se, in case of Go e.g. `new`, `append`, `make`,
len, ...
2) That's the essence of "I don't like this approach".
3) IMO not. `_<arch>` is external to both the language as it is to any
built-ins/predeclared stuff.

Comment 7:

I never said `_<arch>` was part of the language, i said it was a concept!

Comment 8:

Adding a builtin is a language change. This doesn't merit a language change.
If we need to support baked-in copies of binary data - and that's
unclear to me - then it would be easy to define:
package resource
func Load(name string) ([]byte, error)
func Install(name string, data []byte)
and then have the "resource compiler" arrange to call resource.Install
during a func init. No language change needed.
However, I am not suggesting that we do this. It's a big topic and
it's unclear that that's the right API. I'm merely pointing out that
it doesn't require a language change.
Russ

Comment 9:

The golang-nuts discussion points out 
    https://bitbucket.org/tebeka/nrsc
    https://github.com/jteeuwen/go-bindata

Status changed to WontFix.

Comment 10:

Yes, but this is a request for a standardized method to do this that is automatically
run on build - not by invoking a 3rd party binary afterwards.