4 ms·

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 i

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.
  - deleted 7y ago
    [deleted]
- 0815test 7y ago
  > 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. This has zilch to do with not being community led, so perhaps the complainers should fish for better arguments. Rust makes the exact same call wrt. this particular issue, and it's very much a community-led language, with a public RFC process.
  - steveklabnik 7y ago
    Rust does support multiple major versions of dependencies in a build. The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.
    - 0815test 7y ago
      Yes, but the folks who are now complaining about Go not being 'community-led' enough were pushing for a module system ("dep") that does not allow for this, and being told that not allowing multiple major versions in the same build was indeed a major problem (and even a showstopper) with their approach. I'm just pointing out that this is clearly a bad argument for calling Go "not community led"! Sorry if that was unclear.
    - mcguire 7y ago
      Wait just a second! :-) 1. Yay! 2. Yes, native libraries would be difficult. Or impossible. 3. Could you elaborate on the "-sys pattern"?
      - steveklabnik 7y ago
        https://doc.rust-lang.org/stable/cargo/reference/build-scripts.html#a-sys-packages https://doc.rust-lang.org/stable/cargo/reference/build-scrip...
geodel 7y ago
Reminds of Java modularity debates, where OSGI folks kept railing against approach Core Java people in Oracle were taking. In Java's case it took really long time for Oracle to prevail over self-appointed community leaders and modularity experts pushing OSGI and come up with better solution. I am happy that similar kind of situation did not prevail for that long in Go's case.
- mcguire 7y ago
  IIRC, one of the major differences between OSGi and the Java modules work (Jigsaw?) was that OSGi had major.minor.micro.stringy version numbers and Java had to have giant.major.minor.micro.stringy because Java's versions would always start with "1.". And the final Java module system is much less flexible than OSGi (which is much more than a module system, which in turn is both a strength and a weakness in this case). Or do Java modules support multiple versions of the same package?

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.
- deleted 7y ago
  [deleted]
0815test 7y ago
> 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. This has zilch to do with not being community led, so perhaps the complainers should fish for better arguments. Rust makes the exact same call wrt. this particular issue, and it's very much a community-led language, with a public RFC process.
- steveklabnik 7y ago
  Rust does support multiple major versions of dependencies in a build. The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.
  - 0815test 7y ago
    Yes, but the folks who are now complaining about Go not being 'community-led' enough were pushing for a module system ("dep") that does not allow for this, and being told that not allowing multiple major versions in the same build was indeed a major problem (and even a showstopper) with their approach. I'm just pointing out that this is clearly a bad argument for calling Go "not community led"! Sorry if that was unclear.
  - mcguire 7y ago
    Wait just a second! :-) 1. Yay! 2. Yes, native libraries would be difficult. Or impossible. 3. Could you elaborate on the "-sys pattern"?
    - steveklabnik 7y ago
      https://doc.rust-lang.org/stable/cargo/reference/build-scripts.html#a-sys-packages https://doc.rust-lang.org/stable/cargo/reference/build-scrip...

geodel 7y ago

Reminds of Java modularity debates, where OSGI folks kept railing against approach Core Java people in Oracle were taking. In Java's case it took really long time for Oracle to prevail over self-appointed community leaders and modularity experts pushing OSGI and come up with better solution. I am happy that similar kind of situation did not prevail for that long in Go's case.

mcguire 7y ago
IIRC, one of the major differences between OSGi and the Java modules work (Jigsaw?) was that OSGi had major.minor.micro.stringy version numbers and Java had to have giant.major.minor.micro.stringy because Java's versions would always start with "1.". And the final Java module system is much less flexible than OSGi (which is much more than a module system, which in turn is both a strength and a weakness in this case). Or do Java modules support multiple versions of the same package?