6 ms·

I have a lot of faith in the Go folks, as I've found the language to be a pleasure to work with in practice -- basically very well-thought-out. But man, I don'

by dilap 12y ago

I have a lot of faith in the Go folks, as I've found the language to be a pleasure to work with in practice -- basically very well-thought-out. But man, I don't know...having to manually run a generate command when eg changing string constants seems pretty weird. And if you change the constants without rerunning go generate (manually!) you may get nonsense values. It seems pretty creaky! Maybe it will end up working out well in practice. (As Go tends to do.)

dsymonds 12y ago
It doesn't really happen all that often in practice, and when you're hacking on a package that relies on this it's easy enough to have `go generate && go test` sitting in your shell history for that iteration cycle.
- dilap 12y ago
  Well, I think the jury's still out, since there hasn't been a lot of use in the wild yet. I realize it can be quite frustrating to get negative feedback from people who haven't even used a feature yet, so I hope I'm not coming across as overly negative. I am overall a huge fan of Go :) And I do appreciate the minimalistic nature of the approach... I expect we'll start to see people do a lot of generics-type stuff with this -- e.g., add an go:generate annotation to get a customized Foo collection or whatever. It'll be interesting to see how it shakes out.
  - blakecaldwell 12y ago
    I imagine most of the complaining is by people that haven't even spent much time in the language, let alone this new tool. I'm would wager that generics were a driving force behind this. They don't want to add them to the language (fair), but are willing to offer a way for us to add them at precompile time.
    - mseepgood 12y ago
      > I'm would wager that generics were a driving force behind this. The driving forces were yacc, protocol buffers, enum strings, unicode tables, encoding/decoding arrays, time zone data. That's what they use it for.
    - lomnakkus 12y ago
      How would that work? AFAIU the idea is that library authors check in the generated code -- so a consumer of your code wouldn't be able to (or at least would be actively discouraged from) generate new code for a library. And thus wouldn't be able to generate "instances" for generic code.
      - blakecaldwell 12y ago
        I haven't spent much time looking into this, and haven't used it yet, but from the Stringer example, they're providing us with a tool to generate strings for enum values. That same approach could be used to generate support for typed collections for your types. I could make the collection-generating code, and you could generate the collections for your types.
        lomnakkus 12y ago
        Yeah, for your types, but if I'm a provider of a library of generic data structures (which is what the people asking for generics are probably thinking about), you're out of luck since I have no way of letting you generate appropriate instances.
regecks 12y ago
I haven't had an opportunity to use `go generate` yet, but yeah, I feel like there's a missed opportunity to integrate it with `go run`/`go build`.
- dsymonds 12y ago
  `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.
SeoxyS 12y ago
Something which using Make would've fixed, incidentally. One of the neat things about Make is that you can define arbitrary dependencies (e.g. pill_strings.go depends on pill.go) and Make knows to rerun the tool when needed.

by dilap 12y ago

dsymonds 12y ago

It doesn't really happen all that often in practice, and when you're hacking on a package that relies on this it's easy enough to have `go generate && go test` sitting in your shell history for that iteration cycle.

dilap 12y ago
Well, I think the jury's still out, since there hasn't been a lot of use in the wild yet. I realize it can be quite frustrating to get negative feedback from people who haven't even used a feature yet, so I hope I'm not coming across as overly negative. I am overall a huge fan of Go :) And I do appreciate the minimalistic nature of the approach... I expect we'll start to see people do a lot of generics-type stuff with this -- e.g., add an go:generate annotation to get a customized Foo collection or whatever. It'll be interesting to see how it shakes out.
- blakecaldwell 12y ago
  I imagine most of the complaining is by people that haven't even spent much time in the language, let alone this new tool. I'm would wager that generics were a driving force behind this. They don't want to add them to the language (fair), but are willing to offer a way for us to add them at precompile time.
  - mseepgood 12y ago
    > I'm would wager that generics were a driving force behind this. The driving forces were yacc, protocol buffers, enum strings, unicode tables, encoding/decoding arrays, time zone data. That's what they use it for.
  - lomnakkus 12y ago
    How would that work? AFAIU the idea is that library authors check in the generated code -- so a consumer of your code wouldn't be able to (or at least would be actively discouraged from) generate new code for a library. And thus wouldn't be able to generate "instances" for generic code.
    - blakecaldwell 12y ago
      I haven't spent much time looking into this, and haven't used it yet, but from the Stringer example, they're providing us with a tool to generate strings for enum values. That same approach could be used to generate support for typed collections for your types. I could make the collection-generating code, and you could generate the collections for your types.
      - lomnakkus 12y ago
        Yeah, for your types, but if I'm a provider of a library of generic data structures (which is what the people asking for generics are probably thinking about), you're out of luck since I have no way of letting you generate appropriate instances.

regecks 12y ago

I haven't had an opportunity to use `go generate` yet, but yeah, I feel like there's a missed opportunity to integrate it with `go run`/`go build`.

dsymonds 12y ago
`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.

SeoxyS 12y ago

Something which using Make would've fixed, incidentally. One of the neat things about Make is that you can define arbitrary dependencies (e.g. pill_strings.go depends on pill.go) and Make knows to rerun the tool when needed.