2 ms·

You mention codegening, which is common in Go for a variety of reasons (as I understand the language does not support so much as a red-black binary tree - or an

You mention codegening, which is common in Go for a variety of reasons (as I understand the language does not support so much as a red-black binary tree - or any other containers that aren't part of the syntax - without codegening). An additional reason for codegening is the extreme syntactic simplicity of the language: there is little syntactic sugar and it has a tiny, simple, explicit specification. On the other hand the syntax is also meant to be clear, unambiguous, and human-readable. I was thinking what is good for humans to read might not be the easiest to get programs to output. Question: since you seem to know about Codegening, do you find Go's grammar, syntax, etc to be a good target for codegening? I don't have a more specific question but you could talk about any other feelings you have about codegening against Go (or any other language)

Vendan 8y ago
Having written a data serialization library based on codegen, I would have to say that Go is relatively simple to codegen. One big annoyance is the import system of "if you don't need it, it's an error to import it.", which, while simple enough for manual code, means you have to do extra work while generating code to keep track of what you actually use (i.e. if none of the things are a time.Time, you don't need to import "time"). The other approach is to use stuff like "var _ = time.Now" kind of constructs, which do make the codegen easier, but I personally feel are far dirtier. One very nice feature of go is that the formatter is available as a library (https://golang.org/pkg/go/format/#Source https://golang.org/pkg/go/format/#Source), so you can gen "raw" code and then throw it through the formatter to get nice pretty output.
- dullgiulio 8y ago
  Unused imports are definitely not an unsolved problem: as last step after dumbly generating code, run goimports.
  - Vendan 8y ago
    Never said "unsolved", I said "annoyance". And I tend to write the code to figure it out and do the right thing. My annoyance is with code gens that do https://github.com/golang/protobuf/blob/master/protoc-gen-go/generator/generator.go#L1340-L1343 https://github.com/golang/protobuf/blob/master/protoc-gen-go.... Not even goimports will strip those...

Vendan 8y ago

Having written a data serialization library based on codegen, I would have to say that Go is relatively simple to codegen. One big annoyance is the import system of "if you don't need it, it's an error to import it.", which, while simple enough for manual code, means you have to do extra work while generating code to keep track of what you actually use (i.e. if none of the things are a time.Time, you don't need to import "time"). The other approach is to use stuff like "var _ = time.Now" kind of constructs, which do make the codegen easier, but I personally feel are far dirtier. One very nice feature of go is that the formatter is available as a library (https://golang.org/pkg/go/format/#Source https://golang.org/pkg/go/format/#Source), so you can gen "raw" code and then throw it through the formatter to get nice pretty output.

dullgiulio 8y ago
Unused imports are definitely not an unsolved problem: as last step after dumbly generating code, run goimports.
- Vendan 8y ago
  Never said "unsolved", I said "annoyance". And I tend to write the code to figure it out and do the right thing. My annoyance is with code gens that do https://github.com/golang/protobuf/blob/master/protoc-gen-go/generator/generator.go#L1340-L1343 https://github.com/golang/protobuf/blob/master/protoc-gen-go.... Not even goimports will strip those...