3 ms·

> This means your conversation is focusing on the tool which isn't the abstraction I'm emphasizing. Your edit implies that I'm talking about a useless tool tha

> This means your conversation is focusing on the tool which isn't the abstraction I'm emphasizing. Your edit implies that I'm talking about a useless tool that can't do anything in the absence of Google, which simply isn't true. The Go Modules tooling does not depend on any central resource to work. Google could shut down tomorrow, and nothing would change for existing projects. The go CLI tools would still be able to find, download, and verify the dependencies. I would still be able to add new dependencies, and the tooling would be able to fetch those. What are you talking about, if not a functional package management system? Google's websites are nice, but they're not required for everything to Just Work. Anyone in the C++ community could stand those websites up at any time after the package management tooling came into existence. They're not required for the functionality of the package manager. > It's relevant if the particular person wondering "why C++ doesn't have a package manager?!?" uses a mental of model of how npm and cargo work. They don't have to know if it's github vs gitlab vs somewhere else. The tool just works without thinking about the location. That's what a canonical repo as a default convention for the client tool provides. Go's CLI tooling literally doesn't provide any way to search for packages at all. You may think it's a requirement, but it's really not! Go requires you to know where the dependency is located, because Go sure doesn't unless you tell it! It feels like I'm really awful at explaining things.

jasode 6y ago
>Go's CLI tooling literally doesn't provide any way to search for packages at all. You may think it's a requirement, but it's really not! You're still misunderstanding the level of abstraction I'm emphasizing for what a "package manager" means to many people. Let's dissect the following command from the Javascript ecosystem: npm install react Notice that the end user does not need to know whether React is hosted on GitHub or GitLab or Facebook's own servers. He doesn't even have to do a google search. The npm command just "magically" gets the React library. Exactly _how_ does npm do that? From _where_ does npm fetch? The _how_ & _where_ is what the majority of my comment is about. All your explanations of Go not working that way does not address that mental model at all. So you have 2 concepts in a "package manager": (1) npm, the client command line tool (2) the canonical default repo that npm tool points to -- and it's a virtuous cycle of easy use and trust because almost everybody publishes to it. It has grabbed mindshare. You keep saying Go doesn't need (2) but I'm saying that doesn't change the fact that many mentally include (2) of what a comprehensive package manager _is_. And is (2) really that unreasonable? Consider the Go documentation example of "adding a dependency" from https://blog.golang.org/using-go-modules#TOC_3 https://blog.golang.org/using-go-modules#TOC_3 -- it has this example output: go: finding rsc.io/quote v1.5.2 go: downloading rsc.io/quote v1.5.2 ... exactly _where_ is it downloading the "rsc.io/quote" package if the user does not manually specify Github/Gitlab/PrivateEnterpriseRepo ?
- coder543 6y ago
  Sure, someone would complain. Just because some people would complain about the absence of one feature that you say is impractical to implement doesn't mean you should avoid implementing the rest of the thing. That's the classic "throwing the baby out with the bathwater" thing. The benefits of a standardized package manager seem worth a few people complaining. I'm sure someone somewhere would probably even complain that they would rather be writing JavaScript or another, non-C++ language, no matter how good the C++ package manager is. Go has proven that a good package manager can work without that feature. You say that feature is something the C++ Committee could never tackle. My whole statement has been "fine, learn from Go!" Instead, you keep harping on this nice-to-have feature and saying it can't be done. Package management is solvable in a way that suits C++. It seems inevitable that standardized package management will eventually happen for C++. I understand your perspective now, but I just don't think I agree with it.
- coder543 6y ago
  > ... exactly _where_ is it getting the "rsc.io/quote" package if the user doesn't manually specify Github/Gitlab/PrivateEnterpriseRepo It's getting it from https://rsc.io/quote https://rsc.io/quote I don't understand what's confusing about this... it's literally specified in the name of the package. Russ Cox is hosting his packages at rsc.io, which is a personal domain name he owns. If you visit it with a normal browser, he just kicks you over to pkg.go.dev, because he doesn't want to put in the effort to make a website for your human consumption. He's just hosting some packages there. I really, really feel like you need to spend some time with Go Modules. You don't really seem to be getting the decentralized nature of it. But it works, and it works well! In this case, Russ Cox has a meta tag there that tells the Go tool to download it from GitHub: <meta name="go-import" content="rsc.io/quote git https://github.com/rsc/quote https://github.com/rsc/quote"> But there's nothing stopping him from actually exposing a git repo at https://rsc.io/quote https://rsc.io/quote, instead of just exposing a redirect. By telling people to use that package URL, he has the flexibility to change how and where he hosts the package in the future.
- deleted 6y ago
  [deleted]

jasode 6y ago

>Go's CLI tooling literally doesn't provide any way to search for packages at all. You may think it's a requirement, but it's really not! You're still misunderstanding the level of abstraction I'm emphasizing for what a "package manager" means to many people. Let's dissect the following command from the Javascript ecosystem: npm install react Notice that the end user does not need to know whether React is hosted on GitHub or GitLab or Facebook's own servers. He doesn't even have to do a google search. The npm command just "magically" gets the React library. Exactly _how_ does npm do that? From _where_ does npm fetch? The _how_ & _where_ is what the majority of my comment is about. All your explanations of Go not working that way does not address that mental model at all. So you have 2 concepts in a "package manager": (1) npm, the client command line tool (2) the canonical default repo that npm tool points to -- and it's a virtuous cycle of easy use and trust because almost everybody publishes to it. It has grabbed mindshare. You keep saying Go doesn't need (2) but I'm saying that doesn't change the fact that many mentally include (2) of what a comprehensive package manager _is_. And is (2) really that unreasonable? Consider the Go documentation example of "adding a dependency" from https://blog.golang.org/using-go-modules#TOC_3 https://blog.golang.org/using-go-modules#TOC_3 -- it has this example output: go: finding rsc.io/quote v1.5.2 go: downloading rsc.io/quote v1.5.2 ... exactly _where_ is it downloading the "rsc.io/quote" package if the user does not manually specify Github/Gitlab/PrivateEnterpriseRepo ?

coder543 6y ago
Sure, someone would complain. Just because some people would complain about the absence of one feature that you say is impractical to implement doesn't mean you should avoid implementing the rest of the thing. That's the classic "throwing the baby out with the bathwater" thing. The benefits of a standardized package manager seem worth a few people complaining. I'm sure someone somewhere would probably even complain that they would rather be writing JavaScript or another, non-C++ language, no matter how good the C++ package manager is. Go has proven that a good package manager can work without that feature. You say that feature is something the C++ Committee could never tackle. My whole statement has been "fine, learn from Go!" Instead, you keep harping on this nice-to-have feature and saying it can't be done. Package management is solvable in a way that suits C++. It seems inevitable that standardized package management will eventually happen for C++. I understand your perspective now, but I just don't think I agree with it.
coder543 6y ago
> ... exactly _where_ is it getting the "rsc.io/quote" package if the user doesn't manually specify Github/Gitlab/PrivateEnterpriseRepo It's getting it from https://rsc.io/quote https://rsc.io/quote I don't understand what's confusing about this... it's literally specified in the name of the package. Russ Cox is hosting his packages at rsc.io, which is a personal domain name he owns. If you visit it with a normal browser, he just kicks you over to pkg.go.dev, because he doesn't want to put in the effort to make a website for your human consumption. He's just hosting some packages there. I really, really feel like you need to spend some time with Go Modules. You don't really seem to be getting the decentralized nature of it. But it works, and it works well! In this case, Russ Cox has a meta tag there that tells the Go tool to download it from GitHub: <meta name="go-import" content="rsc.io/quote git https://github.com/rsc/quote https://github.com/rsc/quote"> But there's nothing stopping him from actually exposing a git repo at https://rsc.io/quote https://rsc.io/quote, instead of just exposing a redirect. By telling people to use that package URL, he has the flexibility to change how and where he hosts the package in the future.
deleted 6y ago
[deleted]