Go 语言是谷歌的,而非社区的

2019-06-13 17:09:17 +08:00
 Cbdy
11666 次点击
所在节点    Go 编程语言
90 条回复
darknoll
2019-06-14 12:19:45 +08:00
没毛病撒,觉得有问题的可以不用 go 转投其他语言啊
testeststs
2019-06-14 12:26:05 +08:00
@passerbytiny
JSL ???
greenskinmonster
2019-06-14 12:30:57 +08:00
自己 fork 一个,然后无条件接受任何 PR 就好了,这样就能保证 go 属于每一个人。
testeststs
2019-06-14 12:31:49 +08:00
@gramyang
那已有的项目呢?
zpf124
2019-06-14 12:39:12 +08:00
@FrankHB

JSR = Java Specification Requests java 语法规范提案

不论叫不叫 JLS 只要你这个是一个 JVM,并且发布给别人用了, 你就不能实现 JSR 定义以外的私货, 这是 java 跨平台的
确实是用技术以外的方式限制.

如果照你这么说 整个软件开发行业大部分都是靠技术以外的东西限制的, 而开源世界则是 100%靠技术以外的东西限制的.





"连询问 JCP 制定的 JSR 跟 Oracle 制定的 JSL 之间的区别都是禁忌"
"至于 SO 问题关不关和关闭的理由是不是可笑的问题本来就看脸,没什么参考性。"

一边说 是可笑的,没什么参考性, 一边用这个 可笑的案例得出了 JLS 和 JSR 是禁忌.


你搜不到 JLS 正是因为它不重要, JSR JEP 都不是它定的 谁没事回去关注它
passerbytiny
2019-06-14 12:58:29 +08:00
@zpf124 #75 你这对“实现”的理解是真心独特。那么请问,ArrayList 中的 Array,对于 List 来说是不是私货。
szq8014
2019-06-14 14:19:22 +08:00
@xfriday 因为你的回答没有任何建设性意义,本末倒置,java 是跟 Oracle 有关系,但是就是因为这事所以才讨论 go 是 google 的前提下还要不要去信 go 让 go 继续发展壮大。
whp1473
2019-06-14 14:36:59 +08:00
@ssynhtn lua 算么?
libook
2019-06-14 16:28:20 +08:00
商业组织的开源项目和非盈利组织的开源项目从根本目标来说,还是不一样的。

其实开源界一直都有 Copyright 和 Copyleft 以及 free 和 non-free 的区别,我们可能听说过很多开源的好处,但绝大多数都是在 free 以及 Copyleft 下有效的,很多商业驱动的开源项目都只是商业组织对开源社区的单方面输出,确实能促进相关行业的发展,但是实际上也是对行业的一种控制手段,Android(看华为,虽然能用 AOSP 源码,但市场是被 Google Play Framework 控制的)、Chromium (掌握市场的是 DRM 之类的非开放组件)也都是这样的。

不过 Go 可能好一点是,在 License 里没有写明 Google 拥有 Go 的 Copyright (写的是“ Authors ”),所以如果想公道一些的话,社区贡献者中增加非 Google 员工的比例就可以了。

Mozilla 的很多项目是 MPL2.0 授权的,是 Copyleft,但不清楚为啥 Rust 是 Apache2.0+MIT 的,但至少 Mozilla 基金会是具有非盈利性质的血统的,做决策不会太看重商业利益。

一个很现实的情况是,商业公司做了很多高质量的代码,非常好用,不需要外人再来做什么工作去完善,以至于助长了大量的伸手党,最后对于伸手党的惩罚也出现了——参考 Ant-design 事件。

然后现在有很多个人开发者也在使用一些 Copyright 非常强的协议,比如 MIT,对其他贡献者不友好,所以也基本上封杀了发展为社区的可能性。
FrankHB
2019-06-17 22:07:22 +08:00
@zpf124 虽然 Java 和 JVM 耦合有些过头,JLS 原则上不管 JVM,后者由 JVMS (Java Virtual Machine Specification) 规范。两者一定程度上是独立的。
例如 Dalvik 上能实现的 Java 能符合 JLS,但 Dalvik 不符合 JVMS。这也体现出加了私货在名义上有问题,但实际上能(单向)兼容的情况(虽然不是 Java 语言这个层次上的)。
很遗憾(?),现状就是 spec 本身约定的技术没法限制这些使用。(当然,法律一定意义上倒是可以算另一个次元的技术……)
JLS 的确是有自身特殊的鸡肋,一个原因是实际起到作用的各种平台规范太多而架空了(有很多不同方面的现象,例如,JavaSE 这个配置在 Java 生态的占比的弱小,再如 JLS 过分依赖 JVMS )。
这根本上也不是技术问题;这造成的文档等支撑项目的维护成本就技术角度上其实是很不经济的,只不过所有权人看上去不在乎这个(或者有意乐意这样抬高某些门槛)罢了。
但无论 JLS 在整个体系里的存在感多弱,都改变不了 JLS 是用来规范 Java 语言本身的首要文档这个事实。要推翻这点只能靠标题党诈欺了,还没谁做到。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/573627

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX