logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

pkg-go-dev-sucks.md (4512B)

    

  1. ---
  2. date: 2020-08-01
  3. layout: post
  4. title: pkg.go.dev is more concerned with Google's interests than good engineering
  5. tags: [go]
  6. ---
  8. pkg.go.dev sucks. It's certainly *prettier* than godoc.org, but under the
  9. covers, it's a failure of engineering characteristic of the Google approach.
  11. Go is a *pretty good* programming language. I have long held that this is not
  12. attributable to Google's stewardship, but rather to a small number of language
  13. designers and a clear line of influences which is drawn entirely from outside of
  14. Google — mostly from Bell Labs. pkg.go.dev provides renewed support for my
  15. argument: it has all the hallmarks of Google crapware and none of the
  16. deliberate, good engineering work that went into Go's design.
  18. It was apparent from the start that this is what it would be. pkg.go.dev was
  19. launched as a closed-source product,
  20. [justified](https://blog.golang.org/pkg.go.dev-2020) by pointing out that
  21. godoc.org is too complex to run on an intranet, and pkg.go.dev has the same
  22. problem. There are many problems to take apart in this explanation: the
  23. assumption that the only reason an open source platform is desirable is for
  24. running it on your intranet; the unstated assumption that such complexity
  25. is necessary or agreeable in the first place; and the
  26. [systemic](https://github.com/golang/go/issues/25443) [erosion](https://github.com/golang/go/issues/30029)
  27. of the existing (and simple!) tools which *could* have been used for this
  28. purpose prior to this change. The attitude towards open source was only changed
  29. following pkg.go.dev's harsh reception by the community.
  31. But this attitude *did* change, and it is open-source now[^1] [^2], so let's give
  32. them credit for that. The good intentions are spoilt by the fact that pkg.go.dev
  33. fetches the list of modules from [proxy.golang.org](https://proxy.golang.org/):
  34. a closed-source proxy through which all of your go module fetches are being
  35. routed and tracked (oh, you didn't know? They never told you, after all).
  36. Anyway, enough of the gross disregard for the values of open source and user
  37. privacy; I *do* have some technical problems to talk about.
  39. [^1]: Setting aside the fact that the production pkg.go.dev site is amended with closed-source patches.
  40. [^2]: The GitHub comment explaining the change of heart included a link to a Google Groups discussion which requires you to log in with a Google account in order to *read*.[^3] If you go the long way around and do some guesswork searching the archives yourself, you [can find it](https://groups.google.com/d/msg/golang-dev/mfiPCtJ1BGU/ibeimu3WEgAJ) without logging in.
  41. [^3]: Commenting on Go patches also requires a Google account, by the way.
  43. One concern comes from a blatant failure to comprehend the fundamentally
  44. decentralized nature of git hosting. Thankfully, git.sr.ht is supported now[^4]
  45. — but only *the* git.sr.ht, i.e. the hosted instance, not the software.
  46. pkg.go.dev hard-codes a list of centralized git hosting services, and completely
  47. disregards the idea of git hosting as *software* rather than as a *platform*.
  48. Any GitLab instance other than gitlab.com (such as
  49. [gitlab.freedesktop.org](https://gitlab.freedesktop.org) or
  50. [salsa.debian.org](https://salsa.debian.org/public)); any
  51. [Gogs](https://gogs.io/) or [Gitea](https://gitea.io/en-us/) like
  52. [Codeberg](https://codeberg.org); cgit instances like
  53. [git.kernel.org](https://git.kernel.org/); none of these are going to work
  54. unless every host is added and the list is kept up-to-date manually. Your
  55. intranet instance of cgit? Not a chance.
  57. [^4]: But not hg.sr.ht!
  59. They were also given an opportunity here to fix a long-standing problem with Go
  60. package discovery, namely that it requires every downstream git repository host
  61. has to (1) provide a web interface and (2) include *Go-specific* meta tags in
  62. the HTML. The hubris to impose your *programming language*'s needs onto a
  63. language-agnostic version control system! I asked: they have no interest in the
  64. better-engineered — but more worksome — approach of pursing a
  65. language agnostic design.
  67. The worldview of the developers is whack, the new site introduces dozens of
  68. regressions, and all it really improves upon is the visual style — which
  69. could trivially have been done to godoc.org. The goal is shipping a shiny new
  70. product — not engineering a good solution. This is typical of Google's
  71. engineering ethos in general. pkg.go.dev sucks, and is added the large (and
  72. growing) body of evidence that Google is bad for Go.