4 ms·

That go doc does not currently handle rust traits, a feature that has no equivalent in Go, is a pointless observation. Rust doc shows traits together with the c

That go doc does not currently handle rust traits, a feature that has no equivalent in Go, is a pointless observation. Rust doc shows traits together with the class they are implemented for, so a “rust doc std::vec::Vec” should print them too. The point is that Rust is behind Go on convenient documentation access, which is ironic seeing that Rust requires documentation access much more than Go. go doc also accesses all documentation for packages used in a project, making it do quite a lot more than grep.

masklinn 5y ago
As far as I know you are, once again, completely wrong. `go doc` looks up symbols in a single package, which is the current package by default. That is what go doc's own documentation states.
- arghwhat 5y ago
  If you had tried using it or otherwise knew what you were talking about you would know that you use it by specifying relative or absolute import paths for any package fetched with go mod or $GOPATH. Just in case this needs an ELI5: it queries project packages to print the relevant documentation for any accessible component: “go doc container/list.List” - bar any typos from a phone keyboard - prints all documentation for the stdlib linked list. In case Rust had a decent doc tool it would be the equivalent of “rust doc std::collections::LinkedList”. (And no, that the Go tool needs to do less work to find all relevant documentation than a Rust equivalent is not relevant to the discussion.)
  - masklinn 5y ago
    Thank you for once again proving the point which you keep missing: you have to give `go doc` a path to a module, which means you have to know where the symbol you’re looking up lives. Which has nothing to do with the article, or my comments. The entire issue of the comment is that Eli has a symbol whose origin they don’t know. Where the symbol comes from is 75% of the question. Of course if you want the documentation of a symbol whose full qualification you know `go doc` gives you that, that’s what I wrote above. But it’s not TFA’s problem, and thus not the problem anyone’s trying to solve here.

masklinn 5y ago

As far as I know you are, once again, completely wrong. `go doc` looks up symbols in a single package, which is the current package by default. That is what go doc's own documentation states.

arghwhat 5y ago
If you had tried using it or otherwise knew what you were talking about you would know that you use it by specifying relative or absolute import paths for any package fetched with go mod or $GOPATH. Just in case this needs an ELI5: it queries project packages to print the relevant documentation for any accessible component: “go doc container/list.List” - bar any typos from a phone keyboard - prints all documentation for the stdlib linked list. In case Rust had a decent doc tool it would be the equivalent of “rust doc std::collections::LinkedList”. (And no, that the Go tool needs to do less work to find all relevant documentation than a Rust equivalent is not relevant to the discussion.)
- masklinn 5y ago
  Thank you for once again proving the point which you keep missing: you have to give `go doc` a path to a module, which means you have to know where the symbol you’re looking up lives. Which has nothing to do with the article, or my comments. The entire issue of the comment is that Eli has a symbol whose origin they don’t know. Where the symbol comes from is 75% of the question. Of course if you want the documentation of a symbol whose full qualification you know `go doc` gives you that, that’s what I wrote above. But it’s not TFA’s problem, and thus not the problem anyone’s trying to solve here.