3 ms·

`go generate` is deliberately not integrated with the other commands because it should not be used for things that are necessary when you just want to use a pac

`go generate` is deliberately not integrated with the other commands because it should not be used for things that are necessary when you just want to use a package. We don't want to force people to have to install random development tools just to be able to compile against someone's Go package.

dilap 12y ago
I love that goal, and certainly one of the pleasures of working w/ Go is how often you don't have to hunt down a world of external dependencies. That said, if I'm reading that code right, if I, say, decide to reorder a constant definition (say swap Aspirin and Ibuprofen), the Go code will still compile, but the string constants will be silently wrong until I realize I need to rerun go generate. No? It's a problem in general: if I modify code that requires rerunning go generate, and I forget or don't realize I need to do it, I'm going to get at best a confusing compiler error, and at worst silently wrong code... Right? Again, maybe this all works fine in practice, but to just brush off these concerns seems a bit glib...
- enneff 12y ago
  They are legitimate concerns, but your given example (re-ordering constants) could break other things silently in any case. There's always a line between risk and convenience. For some people Go is too conservative, and for others it is too liberal.
  - waps 12y ago
    It is just extremely frustrating to see them using contradictory arguments for various parts of the language. This is a very liberal way to do this, which contradicts most of the rest of the language (library dependencies, language itself, features). For instance in this case, the very existence of the code generation libraries contradicts the reflection package. Compile-time function execution would have been so much more consistent it's horrifying : http://dlang.org/mixin.html http://dlang.org/mixin.html Example vaguely similar to Go's example: http://forum.dlang.org/thread/lgunf8$14rp$1@digitalmars.com#post-wavwzktsiboukwlgejsg:40forum.dlang.org http://forum.dlang.org/thread/lgunf8$14rp$1@digitalmars.com#... http://stackoverflow.com/questions/18552454/using-ctfe-to-generate-set-of-struct-aliases/18553026#18553026 http://stackoverflow.com/questions/18552454/using-ctfe-to-ge... But like every other decision in Go, you can either assume the Go developers actually believe the arguments they're putting up ... or you can ask yourself "would the Go compiler/toolchain become easier or harder to implement ?" And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions. And the right solution, mixins + CTFE is legendary hard to implement. As in, someone who's written 3 commercial C++ compilers from scratch has serious trouble getting it to work. But it's such a joy to use.
    - enneff 12y ago
      > And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions That's not accurate. There are a lot of things about Go that are very difficult to implement. The concurrency system and garbage collector are obvious examples. Some less obvious ones are discussed here: http://talks.golang.org/2014/compiling.slide http://talks.golang.org/2014/compiling.slide
      - waps 12y ago
        Let me repeat the last slide from that deck : Conclusion Go is simpler to compile than most languages There are still complexities for the compiler Most complexities stem from making Go easier to write I would also argue that if you take a compiler book, and you look up these problems, they're all solved. That is certainly not true for most other languages such as Prolog, Haskell, Java, Rust or D, especially not at the time they were written. Most of those added a chapter or two to our knowledge of compilers. Or ten, in the case of Haskell.
- dsymonds 12y ago
  I'm not trying to brush off concerns. They're fair, but I don't think it's particularly fatal. If you're using stringer, you've opted into it by adding //go:generate lines to your source, and so if you're messing with your code you just have to remember to run `go generate` (or stick a comment near the constant definition to remind yourself). In practice you won't be messing with the constants a huge amount, and if you're using something like stringer then it's easy to keep that in mind.
  - stock_toaster 12y ago
    What you said makes sense for a single-author codebase. For a shared codebase with many authors, I could envision it being an occasional problem, especially if misused/abused.
    - jdunck 12y ago
      Pre-commit hook should address your concern?
- NateDad 12y ago
  One of the really great things about go generate is that the command to run (and thus the reminder that you need to run it) can and should exist very near to the code that might change. If you see //go:generate stringer -type Pill const ( Placebo Pill = iota Aspirin ) Then you'll probably remember when you add an item to the list that you need to rerun go generate.
  - waps 12y ago
    And if you don't have the dependencies this requires ? Given this design, why would the library author even specify/include the tool required ? Or worse: what if there's a tool called "stringer" on your device that isn't what is on the developer's machine ? Even worse : what if it's subtly different ?
    - NateDad 12y ago
      How is that different than any other way to run external tools? Make or Python or anything else has the exact same problem.

dilap 12y ago

I love that goal, and certainly one of the pleasures of working w/ Go is how often you don't have to hunt down a world of external dependencies. That said, if I'm reading that code right, if I, say, decide to reorder a constant definition (say swap Aspirin and Ibuprofen), the Go code will still compile, but the string constants will be silently wrong until I realize I need to rerun go generate. No? It's a problem in general: if I modify code that requires rerunning go generate, and I forget or don't realize I need to do it, I'm going to get at best a confusing compiler error, and at worst silently wrong code... Right? Again, maybe this all works fine in practice, but to just brush off these concerns seems a bit glib...

enneff 12y ago
They are legitimate concerns, but your given example (re-ordering constants) could break other things silently in any case. There's always a line between risk and convenience. For some people Go is too conservative, and for others it is too liberal.
- waps 12y ago
  It is just extremely frustrating to see them using contradictory arguments for various parts of the language. This is a very liberal way to do this, which contradicts most of the rest of the language (library dependencies, language itself, features). For instance in this case, the very existence of the code generation libraries contradicts the reflection package. Compile-time function execution would have been so much more consistent it's horrifying : http://dlang.org/mixin.html http://dlang.org/mixin.html Example vaguely similar to Go's example: http://forum.dlang.org/thread/lgunf8$14rp$1@digitalmars.com#post-wavwzktsiboukwlgejsg:40forum.dlang.org http://forum.dlang.org/thread/lgunf8$14rp$1@digitalmars.com#... http://stackoverflow.com/questions/18552454/using-ctfe-to-generate-set-of-struct-aliases/18553026#18553026 http://stackoverflow.com/questions/18552454/using-ctfe-to-ge... But like every other decision in Go, you can either assume the Go developers actually believe the arguments they're putting up ... or you can ask yourself "would the Go compiler/toolchain become easier or harder to implement ?" And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions. And the right solution, mixins + CTFE is legendary hard to implement. As in, someone who's written 3 commercial C++ compilers from scratch has serious trouble getting it to work. But it's such a joy to use.
  - enneff 12y ago
    > And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions That's not accurate. There are a lot of things about Go that are very difficult to implement. The concurrency system and garbage collector are obvious examples. Some less obvious ones are discussed here: http://talks.golang.org/2014/compiling.slide http://talks.golang.org/2014/compiling.slide
    - waps 12y ago
      Let me repeat the last slide from that deck : Conclusion Go is simpler to compile than most languages There are still complexities for the compiler Most complexities stem from making Go easier to write I would also argue that if you take a compiler book, and you look up these problems, they're all solved. That is certainly not true for most other languages such as Prolog, Haskell, Java, Rust or D, especially not at the time they were written. Most of those added a chapter or two to our knowledge of compilers. Or ten, in the case of Haskell.
dsymonds 12y ago
I'm not trying to brush off concerns. They're fair, but I don't think it's particularly fatal. If you're using stringer, you've opted into it by adding //go:generate lines to your source, and so if you're messing with your code you just have to remember to run `go generate` (or stick a comment near the constant definition to remind yourself). In practice you won't be messing with the constants a huge amount, and if you're using something like stringer then it's easy to keep that in mind.
- stock_toaster 12y ago
  What you said makes sense for a single-author codebase. For a shared codebase with many authors, I could envision it being an occasional problem, especially if misused/abused.
  - jdunck 12y ago
    Pre-commit hook should address your concern?
NateDad 12y ago
One of the really great things about go generate is that the command to run (and thus the reminder that you need to run it) can and should exist very near to the code that might change. If you see //go:generate stringer -type Pill const ( Placebo Pill = iota Aspirin ) Then you'll probably remember when you add an item to the list that you need to rerun go generate.
- waps 12y ago
  And if you don't have the dependencies this requires ? Given this design, why would the library author even specify/include the tool required ? Or worse: what if there's a tool called "stringer" on your device that isn't what is on the developer's machine ? Even worse : what if it's subtly different ?
  - NateDad 12y ago
    How is that different than any other way to run external tools? Make or Python or anything else has the exact same problem.