与优秀的工程相比，Pkg.go.dev更关心谷歌的利益

Pkg.go.dev太烂了。它当然比godoc.org更漂亮，但在背后，它是谷歌方法的工程学特征的失败。

围棋是一种相当不错的编程语言。我一直认为这不是由于谷歌的管理，而是因为一小部分语言设计者和完全来自谷歌以外的一系列清晰的影响-主要是来自贝尔实验室(Bell Labs)。Pkg.go.dev为我的论点提供了新的支持：它拥有谷歌垃圾软件的所有特征，但没有Go设计中经过深思熟虑的、优秀的工程工作。

从一开始就很明显，这就是它会是什么样子。Pkg.go.dev是作为封闭源码产品发布的，理由是指出godoc.org太复杂，不能在内部网上运行，pkg.go.dev也有同样的问题。在这种解释中有许多问题需要剖析：认为开放源码平台可取的唯一原因是不让它在您的Intranet上运行的假设；未声明的假设，即这种复杂性是必要的或可以接受的；以及对现有的(而且简单的！)。在此更改之前本可以用于此目的的工具。在pkg.go.dev受到社区的严厉欢迎之后，人们对开源的态度才有所改变。

但是这种态度确实改变了，现在它是开源的12，所以让我们对此给予信任。Pkg.go.dev从proxy.golang.org获取模块列表的事实破坏了良好的意图：这是一个封闭源码代理，通过它可以路由和跟踪所有的GO模块获取(哦，您不知道吗？毕竟，他们从来没有告诉过你)。不管怎么说，对开源和用户隐私价值的漠视已经够多了；我确实有一些技术问题要谈。

一种担忧来自于对git主机本质上的去中心化的公然不理解。谢天谢地，现在支持git.sr.ht 3-但只支持git.sr.ht，即托管实例，而不是software.pkg.go.dev硬编码集中的GIT托管服务列表，并且完全忽略将GIT托管作为软件而不是平台的想法。除gitlab.com以外的任何GitLab实例(如gitlab.freedesktop.org或salsa.debian.org)；任何Gog或Gog。您的CGIT内联网实例？没戏。

他们在这里还得到了一个机会来解决Gopackage发现的一个长期问题，即它要求每个下游的GIT存储库主机(1)提供一个Web界面，(2)在HTML中包含特定于Go的元标签。把你的编程语言的需求强加给语言不可知的版本控制系统的狂妄自大！我问：他们对追求语言不可知论设计的更好、更繁琐的方法不感兴趣。

开发人员的世界观是疯狂的，新网站引入了几十个回归，它真正改进的只是视觉风格--这可以在godoc.org上做得平淡无奇。我们的目标是推出一个闪亮的新产品-而不是设计一个好的解决方案。总的来说，这是谷歌典型的工程精神。Pkg.go.dev太烂了，而且添加了大量(且不断增加的)证据，证明谷歌对围棋不利。

撇开生产pkg.go.dev站点使用闭源补丁进行修改的事实不谈。/↩

GitHub的评论解释了改变主意的原因，其中包括一个指向谷歌小组讨论的链接，该讨论要求你使用谷歌账户登录才能阅读。4如果你绕了很长一段路，自己猜测一下档案，不用登录就能找到。--↩。

对我的一篇帖子有什么评论吗？通过发送电子邮件至~sircmpwn/[email protected]，在我的公共收件箱中开始讨论。

您是一名自由软件维护员吗？在您的工作过程中，您是否正在与压力、苛刻的用户、超负荷工作或任何其他社会问题作斗争？请给我发电子邮件-我知道你的感受，我可以倾听你的同情心，分享一些经验丰富的建议。