> 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 for invoking code generation tools; tools that people were already using in a variety of ad hoc ways. That's all. Macros are another thing entirely.
Our conservatism should be a testament to how much we care about quality. We don't want to do anything by half measures, as that serves no one's interests.
(I regularly downvote comments that are negative, and leave comments explaining why I found the comment to be negative).
I actually don't think this was an unfair phrasing. I had actually felt insulted when `go generate` was announced. "You're sweeping [generics et al] under the rug using comment-bound directives and telling me it's an elegant solution to problems? Do you think I'm an idiot?" Was, in fact, very close to what went on in my head when I read that initial post/slideshow.
I don't like to be degrading when it comes to differing opinions on coding practices - if generated code and comment-bound directives are good for you, well, okay - but being told that I should like it and stop questioning? That's insulting.
I think the deeper complaint that's coming through is not that the Go team are bad language designers who don't care about the developer experience, but that they are condescending towards the community. Even if you really, really don't mean to be.
Well, I get quite the opposite impression of condescending with them hanging around HN and golang nuts discussing language issues. And I'm actually fine with them making the decisions in the end. Go wouldnt be as clear and productive as it is today if every request for a feature would find it's way into the language in some half-hearted manner.
Isn't comment-driven code generation kind of the definition of a "feature request implemented in a half-hearted manner"? People asked for generics and got this. It seems like the kind of suggestion most language designers would throw out as unelegant.
If the language is so conservative as people claim, it should have neither macros/generics nor any of these pseudo-macro-generic-y half-measures.
My apologies if I sounded a bit rough. I know and like your conservative approach and respect your work. I just think that's not a good feature, at all. Because once you start adding pragmas in comments, where does it stop? I'm a bit emotional about it because I love Go,I use it everyday and have been successful with it. If i didn't I wouldn't be writing about it.
Fixing the lack of generics is not the intent of supporting a standard way to do code generation. The intent is to allow for things like generating code from protobuf specs and yacc. In fact, there was even debate against adding go:generate because they were afraid people would use it to get something like generics. To say it is for generics is to grossly mischaracterize the feature.
Given that this is the only way Go provides to gain access to generic-like behavior, you shouldn't be surprised when people use it that way, and the intent of the team is quite irrelevant.
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 that never get pulled.
> 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.
Or d) that I have any time in my life to undertake such work.
I'd argue that making the changes you desire in an open-source project and forking the project is immeasurably more productive than complaining about it on HN. (IMHO)
There are many cases where project forks become more popular than the original project itself.
This is an odd comment considering the entire point of this discussion is that a bad choice has been foisted on the project and criticism flatly rejected by the core team. Why do you believe a "better solution" would be accepted?
That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience.
"go generate" is a mechanism for invoking code generation tools; tools that people were already using in a variety of ad hoc ways. That's all. Macros are another thing entirely.
Our conservatism should be a testament to how much we care about quality. We don't want to do anything by half measures, as that serves no one's interests.