Go 语言是谷歌的,而非社区的
我在 Twitter 上面看到这样的一个问题:
有很多人讨论 Go 的泛型,为什么我们不能有一个类似于 Java OpenJDK 那样的东西,比如叫作 OpenGo,社区成员可以自己实现泛型,而不是一直等待官方推出泛型。
对于这个问题,有很多人作了回答,但有一个真实的声音没有被直接表达出来,那就是:Go 是谷歌的编程语言,而不是社区的。
当然,很多社区成员为 Go 语言贡献了很多重要并且有价值的东西,这些从贡献者和提交者的多样性就可以看出来。但谷歌作为整个 Go 社区的守门人,它独自决定什么东西可以被 Go 语言接受,什么不能被接受。即使社区有一套流程来决定什么东西可以被加入到 Go 语言中,但不要忘了房间里还有一头八百磅重的大猩猩。只要是谷歌反对的东西,没有人可以让它们加入到 Go 语言中。同样的,如果谷歌决定要把什么东西加入到 Go 语言中,那是势在必行的。
最为明显的一个例子就是在 Go 语言模块系统上发生的一件事情,谷歌 Go 语言核心团队的一名成员放弃了由外部 Go 社区开发的一个模块系统,因为它使用了另一种不同的模型。可以通过这里查看相关的历史。
简单来说,Go 语言拥有一个贡献者社区,但是它并不是一个社区项目,而是谷歌的一个项目。无论你认为这是好事还是坏事,它都是一个不争的事实,我们需要接受这个事实。如果你认为有一些重要的东西可以加入到 Go 语言中,那么说服 Go 语言核心团队比努力在社区中达成共识来得更有效。
贡献者将大量的时间和精力投入到社区当中,但如果 Go 语言核心团队不买账,就是在浪费时间。最好的结果也不过是让 Go 语言核心团队对这些问题了解得更深入。
一般来说,社区的声音对于 Go 语言的发展来说并不是十分重要,而我们这些谷歌墙外人,只要接受这样的事实就对了。如果足够幸运的话,我们想要的东西正好与谷歌想要的东西契合,谷歌和 Go 语言核心开发团队就会更加关注这些东西,并及时进行相关的工作。好在谷歌和 Go 语言核心团队也比较关心 Go 语言在业界成功与否,所以他们愿意付出代价解决痛点。
不管怎样,Go 语言表现得挺好,它有一个不大的核心团队,这个团队对于这门编程语言有着良好的品味和愿景,但他们听不进外界的声音,缓慢前行,不太愿意拥抱变化。
我喜欢 Go 语言已经有一段时间了,对 Go 语言的演变和 Go 语言核心团队的管理能力基本上感到满意。我认为慢一点推出泛型功能并不是件坏事,但 Go 语言模块系统事件却给我留下了不好的印象,我似乎有点后悔成为 Go 语言贡献者的一员,哪怕只是一些小的改动我也并不乐意(换句话说,我不想成为“二等公民”)。如果发现 bug,我会继续提交 bug 报告,但也仅限于此。
Go 语言的团队声称他们比较关心整个社区,并且希望更多的人参与进来,这种论调让我感觉很可笑。我不否认他们关心社区,但只关心某些特定的方面。我觉得 Go 语言团队与其暗中做小动作,不如坦诚布公地面对这种状况。
谷歌和 Go 语言核心团队
你可能会问,Go 语言到底是谷歌的还是 Go 语言核心团队的。虽然说 Go 语言的一些方向是由核心团队设定的,但核心团队的大部分或者全部成员都是谷歌的员工,所以在实际当中不可能分得很清楚。如果 Go 语言核心团队都离开了谷歌,并积极确立 Go 语言未来的发展方向,那我们或许可以说清楚 Go 语言到底属于谁。如果这件事情真的发生了的话,特别是大多数人不再为谷歌工作,那么 Go 语言就有可能属于这个团队。就像 Python 一样,不论 Guido van Rossum 为谁工作,Python 一直都是他的编程语言。
在实际当中,不能否认的是,谷歌为 Go 语言提供了大量的基础设施和资源,例如域名golang.org等,而且 Go 语言的商标同样也在谷歌的商标列表里面。
本文文字及图片出自 InfoQ
你也许感兴趣的:
- Go语言有个“好爹”反而被程序员讨厌?
- 【外评】为什么人们对 Go 1.23 的迭代器设计感到愤怒?
- 【译文】Go语言性能从 1.0 版到 1.22 版
- Go 语言程序员的进化
- 【译文】面试时,有人问我喜欢Go语言什么?
- 4 秒处理 10 亿行数据! Go 语言的 9 大代码方案,一个比一个快
- 【译文】Go语言设计:我们做对了什么,做错了什么
- 最好的 Go 框架就是不用框架?
- 吵翻了!到底该选 Rust 还是 Go,成 2023 年最大技术分歧
- “Go 语言的优点、缺点和平淡无奇之处”的十年
你对本文的反应是: