3 ms·

Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what

by weego 7y ago

Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?

remus 7y ago
> If it doesn't gain traction then the decisions made by Google are clearly considered the best approach I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language. As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.
- bonesss 7y ago
  > It'd take time and money to [develop a language] Isn't that part of the fundamental conundrum though? If your need is so great, and so common, and so beneficial to get solved then the cost of development should be less than the benefits accrued, and smart business would bring that money and time to bear on the challenge and solve it. As Google has done with the main project... Saying there isn't time enough or money enough to solve the technical challenges sounds like saying those challenges aren't important, or valuable, enough to be prioritized. Which is to say our wallets are in agreement with Googles wallet on the issue of generics in Go. The considered 'best approach' from the community isn't the best technical approach to the technical issues, it's the best balance of pragmatic solutions for produced benefit (ie ROI), that create a sustainable project/product.
Cthulhu_ 7y ago
What has happened in the past is that features developed in a fork make their way back to the mainline - iirc in the Java world this was a thing with the virtual machine, particularly garbage collection. If a hypothetical OpenGo can solve the generics problem in a satisfactory way then it could make its way back into Go. Well, licensing and such notwithstanding.
jacques_chester 7y ago
A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.
- pflats 7y ago
  Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few: >>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency. >Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion. That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article. And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go. [1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...
  - josefx 7y ago
    > Google was saying "from day one" it was a literal showstopper, For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.

by weego 7y ago

Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?

remus 7y ago

> If it doesn't gain traction then the decisions made by Google are clearly considered the best approach I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language. As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.

bonesss 7y ago
> It'd take time and money to [develop a language] Isn't that part of the fundamental conundrum though? If your need is so great, and so common, and so beneficial to get solved then the cost of development should be less than the benefits accrued, and smart business would bring that money and time to bear on the challenge and solve it. As Google has done with the main project... Saying there isn't time enough or money enough to solve the technical challenges sounds like saying those challenges aren't important, or valuable, enough to be prioritized. Which is to say our wallets are in agreement with Googles wallet on the issue of generics in Go. The considered 'best approach' from the community isn't the best technical approach to the technical issues, it's the best balance of pragmatic solutions for produced benefit (ie ROI), that create a sustainable project/product.

Cthulhu_ 7y ago

What has happened in the past is that features developed in a fork make their way back to the mainline - iirc in the Java world this was a thing with the virtual machine, particularly garbage collection. If a hypothetical OpenGo can solve the generics problem in a satisfactory way then it could make its way back into Go. Well, licensing and such notwithstanding.

jacques_chester 7y ago

A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.

pflats 7y ago
Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few: >>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency. >Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion. That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article. And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go. [1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...
- josefx 7y ago
  > Google was saying "from day one" it was a literal showstopper, For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.