6 ms·
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
by 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 agoRust 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 agoYes, 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 agoWait just a second! :-) 1. Yay! 2. Yes, native libraries would be difficult. Or impossible. 3. Could you elaborate on the "-sys pattern"?
- steveklabnik 7y agohttps://doc.rust-lang.org/stable/cargo/reference/build-scripts.html#a-sys-packages https://doc.rust-lang.org/stable/cargo/reference/build-scrip...