1. 37
  1.  

  2. 7

    Hopefully it will soon support Go modules, as properly supporting separate versions is one of the biggest improvements pkg.go.dev has.

    1. 5

      Aye, I intend on looking into this feature when I next need something to do on a rainy day. I think someone else was interested as well. If you’d like to see it sooner rather than later, you might find it easy to do - the gddo codebase, once purged of Google crap, is reasonably accesisble to the typical Go programmer.

      1. 2

        I read through the changelog when I found the project last week; I had previously done some work to cleanup gddo for our internal deployment a few years ago. You and akavel have done a much better job than I (though I was trying to retain AppEngine support, to try to upstream interfaces, alas).

        I thought about adding support for modules, but the implementation details haven’t formed in my mind just yet.

        1. 1

          I didn’t touch the codebase, you probably meant Alexey Yerin, Adnan Maolood and others.

          1. 1

            Yes. I copy and pasted from the wrong spot. I’m sorry for the misattribution.

    2. 4

      Interestingly for those who don’t know, godoc.org was actually originally, and for quite a long time, a personal project and public service by a person AFAIU not related to Google. So this kinda makes it turn a full circle.

      1. 3

        The only thing that is kinda a problem is the fact that I believe that godoc doesn’t support modules/displaying help for a specific version, not that I would need this often as in Go you usually just use the latest one and bump it often.

        1. 2

          We’re interested in developing those features. Want to help?

        2. 4

          io domain are a human rights antipattern. https://en.wikipedia.org/wiki/Expulsion_of_the_Chagossians It bums me out when good things get bad domains.

          1. 2

            this is great! I really prefer the more compact index section in godoc(s).(org|io).

            I tried making the function name bolder since scanning though the list is difficult, will try to send a patch if i find something useful

            1. 1

              Will it be feasible to pull new content from pkg.go.dev? Or is this a sort of soft fork of the Go ecosystem?

              Either way I am delighted with this effort. I am always apprehensive about Go due to the specter of control by Google; building independent community infrastructure is an important bulwark against that. Fighting the good fight!

              Would also like to register my disgust at the .dev TLD.

              1. 3

                This doesn’t host packages, it pulls packages from other sources and displays documentation for them. This is also true of pkg.go.dev. Neither have forked the Go ecosystem.

                1. 1

                  Who maintains the list of where to pull from?

                  1. 3

                    It pulls any package from any source as soon as you type the import path into the search box, or navigate to its URL. There’s no global package list for Go.

                    1. 1

                      So could it just as well be a client program that you run on your own machine?

                      1. 1

                        Yes. Every package on godocs.io works on pkg.go.dev and vice versa.

                        1. 1

                          Almost seems like people would be better off with a local client program rather than a web app, as with email clients vs. web mail.

                          1. 1

                            Perhaps! The main advantage is the ability to link to it from anywhere. Many projects link to it from their README files, or their website, lots of people answer questions on forums or IRC by linking to a specific function’s docs, and so on.

                            1. 1

                              Then you’d want a standard URL scheme that is recognized by every client, maybe something like godoc://9fans.net/go/acme

                              By the way, looking at https://9fans.net/go/acme I am a bit confused. Where does godoc.org pull from if the source redirects to godoc.org?

                              1. 1

                                Oh, I don’t know, installing a new global URL handler just for documentation isn’t really to my taste. I think the web is fine for this situation.

                                Regarding 9fans.net/go/acme, try this: curl https://9fans.net/go/acme

                                1. 1

                                  I understand using the web for the sake of practicality, but having to maintain an entire web app with HTTPS and Postres just so users don’t have to install a client application feels like an ugly artifact of the web which could be overcome.

                                  Maybe a better approach would be to design a protocol that could apply to a broader class of documents but would work just as well for godocs.

                                  1. 2

                                    Nothing stops you from running go doc 9fans.net/go/acme locally and achieving the same effect. It’s a lot harder to link to from the web however.

                                    1. 1

                                      Web browsers are fickle: RSS feeds were viewable until recently. Gopher support was possible with an addon until Firefox Quantum. FTP links work now but won’t for much longer.

                                      Keeping up with the Chrome hamster wheel does not feel worth while, though practical concerns may require it.

              2. 1

                I missed this release. Glad to see an alternative to pkg.go.dev, having more options is nice.

                1. 1

                  As an interested non-Go-user, could someone tell me what this offers that pkg.go.dev doesn’t? Forking and continuing an existing codebase that’s being put down by its original developers? Offering a third-party version of a service that isn’t controlled by Google? Something else?

                  1. 5

                    All of those. It’s also simpler and lighter weight than pkg.go.dev, and gives people a non-Google route to contribute (i.e. no CLA). The codebase is also cleaner and easier to deploy yourself, for example on an intranet, than pkg.go.dev is, and even more so than the original godoc.org codebase after our efforts to clean it up.

                    1. 1

                      and gives people a non-Google route to contribute (i.e. no CLA)

                      Thank you so much for this.

                    2. 5

                      Compare https://pkg.go.dev/github.com/BurntSushi/xgbutil vs https://godocs.io/github.com/BurntSushi/xgbutil

                      One has docs. The other doesn’t.

                      (This is not an invitation to discuss licensing choices.)