It sounds like this is just a clean way to run yacc and protobufs. And: using yacc from Golang programs is in fact ugly right now; it's actually a little worse than it is in C. I think you should just take this document --- whatever it's provenance --- at face value.
> using yacc from Golang programs is in fact ugly right now
Why do you say that, and how does this mechanism affect the use case you have in mind? You run go generate instead of make. The advantage is that you don't have to have make; e.g. Windows and Plan 9 don't have make. Arguably, the advantage is pretty minor, but I don't see how it changes anything in your workflow.
Remember that go generate does not run at build time. You still have to run it manually when you want it (just like before, with make) and commit the generated files into your repository.
Grunt support for Go is patchy, the one package I found is no longer supported, but as I'm writing web stuff the real thing I needed was to do with js compression and obfuscation - I want to deal with nice easy-to-read js files in dev but I don't want to waste my customers' bandwidth delivering comments to their browser.
I understand the argument for go generate as a resolution for some of the problems with no generics (and yes, Go's type system is a bitch. I love the language but rewriting everything for each individual structure gets old fast). I can see how generating boilerplate ORM-a-like code would be great.
So the argument that go generate is somehow a replacement for make leaves me a bit puzzled. I mean, yes, you could do that, but why?
Am I missing how to make this process work with the idiomatic Golang build system? Can I use "make" or "grunt" to create a package that someone else can "go get" and build without using a third tool?
Go generate is for package authors, at which point you check the results into your repo. Then anyone else can go get your package as a dependency and not need to regenerate that code. So, yes.
It's not uncommon in Go programs to have makefiles (or shell scripts) that make some transformation to the code. This imposes no burden to the user since the generated files are checked into the repository, but it does put some burden on the developer (who has to run make), or to the prospective contributor, who not only has to have make, but potentially has to have all other tools invoked by make or learn the varying non-standard mechanism by which code is generated (e.g for the Go project itself, a new developer has to learn how to use the various shell and perl scripts that generate the code in the syscall package).
Go generate does not eliminate this burder for the developer. Someone still has to write the yacc invocation and remember to run it; it won't know how to run itself, but it has the advantage that now there is a standard canonical way to generate code. Anyone can just type go generate instead of learning about makefiles or shell scripts or whatever the project is using. Code generation is normalized under the go generate umbrella.
