31–40 of 222 posts
At last! I'm not insane! I raised this on the golang dev forums and got nowhere: https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOz... The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.
Elegant design...
Want to know what's even worse? Using comments for something but not parsing the syntax tree . In go 1.4, save the following to a file and run 'go generate' on it: https://play.golang.org/p/9WJtxClRXr (I'd make it run in the playground, but you can't 'fork exec', so exec.Command($GOBIN, generate) won't work sadly) Even though that code has no comments (only a multi-line string), go generate will run and print out a '…
That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. Which is amplified by the previous statements regarding for example generics where they said they wont introduce them until they find a really good way to do it but then crank out half bake…
I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?
At last! I'm not insane! I raised this on the golang dev forums and got nowhere: https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOz... The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.
Most interesting response from Russ Cox: "Where you see a hack I see an elegant design." Elegant design...
meh.
I 100% agree. You want macros? I don't like it but think about proper macros. Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with". Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. So don't use comments for anything but documentation generation purpose. .
> Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with", which is ,at the minimum, insulting. Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience. "go generate" is a mechanism fo…
As long as it aligns 100% with the bizarro ideas of the core team regarding comment pragmas, code generation, vendoring, generics, etc.
I also do not agree with that. This is bad for so many reasons. First, to the compiler code, comments should be discarded as soon as possible (often in the lexer). To the programmers, comments should never execute anything (this is just intuitively expected). To any go source code reader (human or machine), comments are supposed to contain only human readable text, probably a context sensitive explanation of that par…
Earlier quoted context omitted.
> Our conservatism should be a testament to how much we care about quality. Offering code generation as a solution to code reuse is not caring about quality, it's laziness.
It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?
Comments are also not metadata! CGO, for example, expects a comment immediately before a special import statement. A blank line between that comment and the import statement means that the comment is not attached to the import statement's AST node, and so is ignored. This confused me a fair amount when I started with CGO. Part of the problem with comment syntax is that it's intentionally lexical and uniform. This sim…
For example for generating a c/c++ enum:
enum example_t
{
#py \
for line in open('values.txt'): \
print('EXAMPLE_' + line.strip() + ',')
EXAMPLE_Max,
EXAMPLE_Unknown
};
enum example_t
{
/* py
for line in open('values.txt'):
print('EXAMPLE_' + line.strip() + ',')
*/
EXAMPLE_Max,
EXAMPLE_Unknown
};
Earlier quoted context omitted.
It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?
Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Saying "it's open source so you can just add feature X or change feature B" only works if you are part of some core team or are respected via other means. Github is littered with projects that have lots of Pull Requests…
There are many cases where project forks become more popular than the original project itself.
This pattern predates Go 1.4, we've had it with CGO and build tags since at least 1.0 AFAIK. Even the Output in examples is pretty old I think. The only advantage in it is backwards compatibility with older Go versions, but in general I agree with you. When PHP did it for Python-style decorators everyone thought it was stupid. And while the build tags in Go are okay by me, doing it for CGO especially seems like a hac…