4 ms·

>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 misunder

by 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]

by jasode 6y ago

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]