No. `go generate` is great for what it was invented for:
Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone.
I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing.
But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers.
Yet again Go ignores decades of programming language research.
> `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research.
Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to.
Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-)
> C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language.
It's exposed through Roslyn (I was technically wrong in that it's not included in the language, but in Visual Studio). It's not very well-documented (to give you some idea of how not well-documented it is, some of the most useful documentation is in a Word file[1]). The code is Open Source[2].
I found out about Roslyn through hearing Erik Meijer speak at a conference. A quick search shows that the content of his talk at the conference I went to is probably covered in his C9 lectures[3], probably in Chapter 8[4]. But I'm pretty sure that will only cover the parser combinators, which is the algorithm, but not the specifics, of how C# is parsed.
When I was doing C# parsing I was working with the CodeDom[5]. If you just need the AST I think ExpressionTrees[6] are now the idiomatic way to generate it, but I'm not sure how that relates to Roslyn.
Disclaimer: My day-to-day development switched over to primarily C/Python/JS about a year and a half ago, so it's been a while since I fired up Visual Studio. My knowledge is probably out of date, and might be flat wrong--nobody's memory is great after a year and a half.
No. `go generate` is great for what it was invented for:
Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone.
Source: https://blog.golang.org/generate
It's not meant as a substitute for generics, it's for running tools such as yacc.