Hacker News new | ask | show | jobs
by IHLayman 2386 days ago
"For code generation and other ancillary tasks, Go includes the 'go generate' facility. This feature was created specifically to free developers from depending on external build tools. (https://blog.golang.org/generate)"

Please please please don't use go generate! While I respect your position, go generate is the worst and I hope they eventually deprecate it in future go versions. We tried go generate in some of our code and it went very badly:

* go generate is placed in a comment line. Comments should never be executable, they should be used for explanation. If I am trying to trace execution, I shouldn't be forced to scan through comments looking for side effects.

* from the go generate man page: "Within a package, generate processes the source files in a package in file name order, one at a time." You can't order your generate commands in a way you want, you have to order them using file order, or keep all of your go generate lines in the same file, which defeats the purpose of go generate.

* go generate will run every time, regardless of freshness of file. So if you need to run protoc or some other protocol buffer compiler, you have to regenerate it every single time regardless of whether or not it is needed which makes the build run way slower.

* What are the dependencies of this project? If I use go generate, I have to run some clumsy grep command to (hopefully) find all of the go generate comments in the package.

Sorry, go generate is to golang what COMEFROM is to INTERCAL. Please avoid if you can help it. If that means a shell script or heaven forbid a makefile, so be it.

1 comments

Go build constraints (build tags) also go in the comments and I think it works well enough. The arguments against are similar to those against struct tags. Without a properly defined pragma paradigm in Go comments at the top of a file work Well Enoughâ„¢ IMO.

I've also never seen anyone call out to protoc from a go generate flag. Sure, you can do that but it hasn't been common in the Go shops I've worked at.

> You can't order your generate commands in a way you want, you have to order them using file order, or keep all of your go generate lines in the same file, which defeats the purpose of go generate.

I've never had a problem with confining generated code to a single file. Do you have more details on why this is a problem? Given that all the files in a package are "flattened" I don't see why this causes a problem...

Tags at least affect the file they're in and no other. Generate lives in one file and does stuff elsewhere.

If I want to know whether a file is built, looking inside is a reasonable thing. If I want to know where generated code comes from, where do I look? How do I know?