On Fri, Mar 13, 2020 at 5:48 AM Jon Perryman <jon.perry...@gmail.com> wrote:
> This comment is from the proposal. Not one person has disagreed with "very > powerful". If you disagree, please say why? How is this not far more > powerful than GO GENERATE, pre-processors and macro's? > No one is disagreeing with that, because it is self-evidently true. But a) talking about the Pros is not how you make a decision. Weighing the Pros and Cons is. And b) even then, "powerful" and "good" are not synonyms. In fact, its powers are specifically why I *don't* like the proposal. Having turing-complete meta-programming means, that it is impossible to trust compilation. It means that any package in the transitive dependency tree can *arbitrarily* extend compile-times. It means you have no assurance that the compilation process is deterministic. It means you have no way to predict what code is actually compiling to. "It's powerful" is *both* on the Pros *and* the Cons list of the decision process. And decisions are made, by weighing both sides of that list. Why isn't a very powerful feature important to everyone? Shouldn't the > compiler developers spend more than 5 minutes consideration on very > powerful features before they dismiss them? Isn't this proposal worth a > "like" just to consider if it's possible? > FTR, to you it might feel like only 5 minutes. But that's because you only perceive the discussion about your specific proposal. The people on the Go team and even just a random person like me have spend *far* more than 5 minutes considering all sorts of ideas for meta-programming. Why do you think `go generate` exists? It didn't used to <https://golang.org/doc/go1.4#gogenerate>. It's because the idea of meta-programming was discussed, at length, repeatedly, and the approach of `go generate` was decided on as the best tradeoff. This proposal is failing because of fear that we will repeat the mistakes > of the past. Great developer's will ask how a powerful feature can be made > safe in their product instead of finding excuses not to consider it. > "liking" a proposal doesn't mean it will be implemented. Instead, it tells > developer's it's important to you and try to find a way to implement that > feature. > I believe it is just as self-evident that it is *impossible* to implement this "safely", as it is self-evident that it would be powerful. And demanding people to spend time on ideas they have already considered thoroughly and rejected, is a denial-of-service attack. > Compile time is not affected if #xxx( xxx ) is not used in the code. > But they are, if it is. And I have little to no control over if my dependencies *do* use it. "If no one uses this feature it has no downsides" is not an argument against the downsides. It's an argument against the feature. > Does GO GENERATE or pre-processors save compile time by reading the source > twice? > I don't understand what source is read twice, in your opinion. But in fact, yes, `go generate` saves compile time. Because it is not called during compilation. It means you can call `go build` without worrying that you are executing arbitrary code. > Are they able to produce results as a programmable GO? > Indeed, yes they can. > do not follow the simplicity and design goals of Go > > Why is this impossible to be part of the requirements? > > > Choose a compile time language. Possibly GO, Python, Java, NodeJS > > or??),which > is a bad idea for a variety of reasons. > > I'm not saying user's have a choice. I'm saying this is a decision to be > made during requirements or design phase. > > > What this proposal describes is a language that is very different from > Go. > > If the language chosen is GO, then it's not different. It could be a brand > new minimal language that is similar to GO. This is a decision to be > discussed. > > > It's even more unlikely that that language would be one as powerful > > Why would you want a powerful language at compile time. You're not reading > files, using goroutines or most other functionality used at run time. > > > It looks like what you want is something like constexpr in C++. > > Constexpr is useless for solving complex problems at compile time (e.g. > gettext). It's amazing how a poorly designed feature get's abused because > the language does not meet our needs. > > > the args can't be evaluated at compile time > > At compile time, everything is a constant. The compiler breaks down #xxx( > yyy ) as constants into AST's. When #xxx is called, the AST's are made > available to the function as ARGS. > > > I used make and awk programs that generate assembly code tuned > > to the exact demands of command line make configuration. Then it builds > in go, then runs. > > I want consistency for everyone, available with GO and easy to use. I'm > sure this worked for you but compile time does not need to be complex. > Simplicity is your friend. > > Thanks, Jon. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAByJhJn584h2AM_kRr8eZaGShfu-FjKxgBwCWpL-Cq11t79svQ%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAByJhJn584h2AM_kRr8eZaGShfu-FjKxgBwCWpL-Cq11t79svQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE57ZBpXJGHS2kWj9BxtN7oDj2oJ%3DhS%3DBsi2CMre-qQNQ%40mail.gmail.com.
