search

hhstore / blog

My Tech Blog: about Mojo / Rust / Golang / Python / Kotlin / Flutter / VueJS / Blockchain etc.
https://github.com/hhstore/blog/issues
294 stars 24 forks source link

Golang: Fucking Go official, Goodbye Go #348

Open hhstore opened 2 years ago

hhstore commented 2 years ago

related:

hhstore commented 2 years ago

艹他妈的 Go 官方: 再见 Go !

update 2022.09:

update:

update: 提案被折叠的内容

最近发生了2个事情:

  1. Go 1.18 发布了, 正式支持泛型[T]. (支持泛型是好事, 恶心的是实现非常丑陋, [T] vs <T>)
  2. Google 内部团队发了个新提案: 引入手动管理内存.(类似社区提案通通被拒, Google 自家人就秒过, 进入"假装讨论阶段")

虚伪的社区治理:

虚伪的 Go 社区讨论:

‼️ 注意: 提案创建时间 + 被官方标记 active 时间. 官方不要逼脸.

image

关于这个社区: (理解能力有问题的, 注意限定上下文...

为什么这么生气?

讨厌这些双标狗们:

为什么一定要对他们竖中指?

hhstore commented 2 years ago

关于 Rust VS Go:

试图把 go 进行 rust 化的做法极其愚蠢:

产品级佐证案例:

案例1:

案例2:

关于 Rust:

关于 Go:

All in Rust:

hhstore commented 2 years ago

关于 Go 泛型提案有多少人讨厌:

来看看 Vlang(类 go 语法)的泛型<T>设计:

泛型:

vlang 支持多返回值:

Go 官方说<> 和 多返回值, 引起语义歧义的说法, 骗骗傻瓜还行!

关于 Go 泛型有多丑陋:

来看一些示例:

具有传染性的特性:

hhstore commented 2 years ago

关于 Python 之禅:

image

关于一些编程设计理念:

如无必要，勿增实体:

BruceDone commented 2 years ago

这个泛型的实现，确实丑的一逼

dengyunsheng250 commented 2 years ago

确实

hhstore commented 2 years ago
image

LS 这位 bestgopher 臭傻逼, 跑过来 BB 一句. 还 block 我. 是 TM 的多玻璃心(太拿自己当盘菜...

你 TM 的瞎吗? 你 来 BB 就算了, 我也会引用你, 客气跟你解释. 你 TM 的 block 我, 还来 BB 个毛线? 我在意多你一个垃圾 block 吗? 傻逼.

特别声明:

hhstore commented 2 years ago

关于辩论:

关于一些装模作样的臭傻逼:

关于此提案(Go 手动GC提案):

关于 Go 泛型提案:

我一个不打算继续写 Go 的人, BB 什么?

关于 Russ Cox:

关于 少数人的暴政:

revintec commented 2 years ago

写的真好,忍不住点个赞.这个issue真是我最近2天最开心的事

lsjbd commented 2 years ago

上一次发生类似的悲剧，还是 godep 团队被集体忽悠的时候，哈哈哈

jiangyuzhao commented 2 years ago

才看到这个issue，支持一下。但是在下觉得go支持泛型就是一个最傻逼的事情，不管用什么方式实现。企图让go rust/c++化的一切行为都是在破坏go自身的语言哲学。issue说到的感觉好像是支持<>泛型实现的，对此在下保留意见。不过还是很高兴有比较清醒的程序员意识到了泛型的侵入性，而不是一群程序员在那边狂欢，觉得go终于变得“高级”了。从go背叛它的语言哲学的那一刻起，go就完了。在下非常讨厌1.18.

huangsuper commented 2 years ago

你喷Go团队的双标，喷Go团队的无视社区，独裁。我都赞同，可为何会扯到国民性格？恶臭？人家白人的傲慢，你拿国人撒气？这种傲慢，你全中国的开发者去社区上书也不会理你。你这样很难在国内获得战友，国外更别想

tmsong commented 2 years ago

这个<>确实。。。emmm

hhstore commented 2 years ago

你喷Go团队的双标，喷Go团队的无视社区，独裁。我都赞同，可为何会扯到国民性格？恶臭？人家白人的傲慢，你拿国人撒气？这种傲慢，你全中国的开发者去社区上书也不会理你。你这样很难在国内获得战友，国外更别想

你可能没注意上下文.

关于"讨论背景":

关于 "恶臭":

关于"傲慢":

hhstore commented 2 years ago

才看到这个issue，支持一下。但是在下觉得go支持泛型就是一个最傻逼的事情，不管用什么方式实现。企图让go rust/c++化的一切行为都是在破坏go自身的语言哲学。issue说到的感觉好像是支持<>泛型实现的，对此在下保留意见。不过还是很高兴有比较清醒的程序员意识到了泛型的侵入性，而不是一群程序员在那边狂欢，觉得go终于变得“高级”了。从go背叛它的语言哲学的那一刻起，go就完了。在下非常讨厌1.18.

关于 go 社区蠢货试图对 go 进行 rust/c/c++ 化:

关于 <T>:

关于 [T]:

@jiangyuzhao

hhstore commented 2 years ago

关于 美式 "言论自由":

来看一下 go 官方的应对: (学习一下...

image

但是, fucking Go official, 他们只能咽下去:

image
hhstore commented 2 years ago

关于 go 官方究竟折叠了什么内容?

查看该评论:

image
hhstore commented 2 years ago

关于"言论自由":

一些其他人的观点:

关于我的"言论自由"观:

以上, 是我一个普通人理解的"言论自由":

全方位比烂的时代:

hhstore commented 2 years ago

题外话:

关于"双标":


群体盲从意识会淹没个体的理性，个体一旦将自己归入该群体，其原本独立的理性就会被群体的无知疯狂所淹没。

—— 古斯塔夫·勒庞《乌合之众》

预设立场的狭隘处: (换位思考

建议理解:

关于独立思考:

关于一些"伪理中客":

关于"信息不对称":

收割:

leeyisoft commented 2 years ago

建议关注一下erlang erlang/otp

hhstore commented 2 years ago

@jiangyuzhao @leeyisoft

更新了 vlang(语法类 go) 的泛型设计:

lait233 commented 2 years ago

字词老哥。有些人跪久了，想让他们站起来都觉得腿麻不肯

CoolkHz commented 2 years ago

支持老哥

hongfs commented 2 years ago

支持老哥

hongfs commented 2 years ago

当我们在讨论言论自由的时候，你可以闭嘴了。

FrankHB commented 2 years ago

Go 的问题暂时不值得我评价，但是认为 <> 简单“正常”的，先手撸个 C++ parser ，或者不会实操讲清楚 < 消歧义解决方案再评论。

需要提醒的是，利用 <> 表示参数化类型的出处是学院派的 ⟨⟩，和 <> 是不同的符号。C++ 继承了 C 等更早期语言在源代码字符集上的抠门，用 <> 代替不在基本字符集中的 ⟨⟩ ，在这里直接付出了严重代价：跨越多个翻译阶段的记号歧义。把 <> 视为正统的观念，是比整个 Go 语言更大的笑话——特别是考虑这些毒害的不只是个别语言而几乎是大半个工业界的用户。

(TODO: +FAQ).

FrankHB commented 2 years ago

再顺带提个问题，关于所谓的多返回值，只用过 ALGOL-like 语言或者四不像语言的用户还是别碰瓷了。

Google "multiple values" 第一个就是 Guile Manual，殊不知 multiple value 在 Scheme 里也是几乎最容易黑出翔的无谓增加设计复杂性的特性——随便一坨 values 和 *-values 就把 spec 连带 formal semantics 都 bloat 了多少？当然，在只用过已经到处 bloat 的语言的用户，没这种敏感性倒也不是不能理解；但更体现出加入半吊子特性时的没事找事。

对剩下的人，认识不到问题是一个原因，另一个原因是语言设计者死活拎不清楚怎么引入满足 multiple values 背后需求的和其它特性整体协调一致的合理设计。虽说不是没有，但极少。也许见识仍然是需要着重鄙视的点；多数 ALGOL-like 语言的用户，能认识个 tuple 这样的舶来品，或许都够我烧高香了。

hhstore commented 2 years ago

Go 的问题暂时不值得我评价，但是认为 <> 简单“正常”的，先手撸个 C++ parser ，或者不会实操讲清楚 < 消歧义解决方案再评论。

需要提醒的是，利用 <> 表示参数化类型的出处是学院派的 ⟨⟩，和 <> 是不同的符号。C++ 继承了 C 等更早期语言在源代码字符集上的抠门，用 <> 代替不在基本字符集中的 ⟨⟩ ，在这里直接付出了严重代价：跨越多个翻译阶段的记号歧义。把 <> 视为正统的观念，是比整个 Go 语言更大的笑话——特别是考虑这些毒害的不只是个别语言而几乎是大半个工业界的用户。

(TODO: +FAQ).

关于 <T> 更简单.

上面文章补充了 vlang(类 go 语法) 的泛型实现方案:

关于 <> 正统概念?

hhstore commented 2 years ago

再顺带提个问题，关于所谓的多返回值，只用过 ALGOL-like 语言或者四不像语言的用户还是别碰瓷了。

Google "multiple values" 第一个就是 Guile Manual，殊不知 multiple value 在 Scheme 里也是几乎最容易黑出翔的无谓增加设计复杂性的特性——随便一坨 values 和 *-values 就把 spec 连带 formal semantics 都 bloat 了多少？当然，在只用过已经到处 bloat 的语言的用户，没这种敏感性倒也不是不能理解；但更体现出加入半吊子特性时的没事找事。

对剩下的人，认识不到问题是一个原因，另一个原因是语言设计者死活拎不清楚怎么引入满足 multiple values 背后需求的和其它特性整体协调一致的合理设计。虽说不是没有，但极少。也许见识仍然是需要着重鄙视的点；多数 ALGOL-like 语言的用户，能认识个 tuple 这样的舶来品，或许都够我烧高香了。

💢 关于multiple values:

至于 Scheme.

hhstore commented 2 years ago

PS:

自己立靶子, 自己喷自己.

FrankHB commented 2 years ago
  • ✅ 这里关于 <T> vs [T]谁更好, 根本不是讨论重点.

不是重点的内容，不配占用这么多篇幅，否则不要奇怪读者误会你的意思。

  • ✅ go 的问题是 []符号 已经被其他语义(数组/字典)大量使用. 数组/字典, 同时在使用[].

我说明的是与此类似但严格地更严重的升级版问题：< 和 > 已经单独被占用表达完全不相关的含义——就是操作符，连分隔符和声明的一部分都不是，而之后又把完全不同的含义强行塞了回去却又不能自然确保在之前的翻译阶段里自动划清界限。这种生殖隔离可比你看到的 Go 里的这些差异严重得多，并且实际造成了严重的实现开销。如果你不同意，认为 Go 的问题比这个性质更恶劣，或者有历史上其它比这个失败更离谱的例子，麻烦给出例子。

为什么我要强调这点？因为 C++ 如此轻率地加入这种实际会极大复杂化设计的“简单”特性，很大的原因就是设计者迁就外行用户，光顾着想着源代码中的具体符号长什么样会怎么“舒服”，而完全不顾全局设计和实现的影响。

就你这里说的泛型问题，整个 C++ 模板也体现了这点：直接多加了一个实例化阶段而没好好考虑阶段之间怎么交互和消除冗余的一般方法，结果什么元编程牛鬼蛇神都上了。当然从实用上你自然有理由指责 Go 的那种半吊子泛型十分垃圾（我不反对甚至还想大笑），但是请注意，你用来对比的其它“泛型”也真没好到哪去。不过要我接手这烂摊子，基本就是像上面有人提的不加泛型了。

  • ✅ 使用 [T] 带来更大代码阅读开销, 会大量出现在和 map[] 混用的地方. 造成代码阅读直线下降.

我完全不反对这点。但是，这不表示用 <> 就能改善到哪去。

关于 <> 更简单.

  • ✅ 看你对简单的理解, 指的是实现层面.

我显然没有单指实现。我说的首先都是设计。但是正式的设计，甚至比实现还扯蛋。我可以让你讨论 parser 的实现思路，是因为我姑且相信让你提“思路”也许实际可行；让你提“设计”，不对照着引用语言规范原文，几乎就没法说话。——这就是这种复杂性扯蛋的地方。

  • ✅ 而我全程讨论的简单指的是代码可读性(更简单). 鸡同鸭讲.

我不觉得设计简单和代码读起来更简单原则上应当矛盾。会出现问题，很大程度上说明语言设计本来就不够简单到让代码自然地简单。

我历来反对让两者渐行渐远的设计。任何不必要地复杂到让人不由自主无法记住的语言规则而被迫瞎蒙什么“经验规则”来替代这些规则进行推理的语言设计，都是因为过度复杂而值得鄙视的候选。

注意这种规则司空见惯到大多数语言用户可能都感知不到，比如 C 语言的经典设计。一些 C 用户不清楚正式规则却又想挑战理解复杂的特性同时心理上自欺欺人地掩盖复杂性，就偷懒用所谓“右左法则”的半吊子规则代替。然而没有理解完整规则，那么就弄不清半吊子在哪，又排除不了反例，所以实际上就是错的。如果要正确理解，那为何需要多一套半吊子？说白了，鄙视谭浩强最鄙视的也就是推销这种二道贩子的私货。

这恰恰是鸡同鸭讲的主要来源：你一句“可读性”听起来堂皇磊落，深究依据却是你想当然的经验（说不好听点的，就是你原创的方便你自己理解的、不可言说的二道贩子规则），除了一些实例能比较，没有公认的参照物来定义清楚什么算“简单”；而我说的简单，是从语言规则的理解和使用（包括实现）到阅读程序的整体体验——尤其是不需要我另外自己发明一套私货——所以我语言复杂直接对着 spec 黑就是了。

顺便，不是我刻意鄙视 ALGOL-like 语言，这些语言的设计者向来就对如何统一这里的简单性少根筋，它们的用户也向来大而化之不求甚解，所以我顺便 cue 一下，是不怕多少误伤的。

  • ✅ 关于 代码可读性 vs 编译器实现开销. 这本来就是取舍问题. 没有讨论必要.

这些本来就不矛盾。要能构成取舍，那么至少还要加上设计者和用户的智商。

很多人都没意识到形式语义可以直接到写出来几乎就是解释器，而编译器在一定程度上只是抽象解释器的特例。

  • ✅ 觉得代码可读性 更重要的. 自然追求语义设计更清晰+直观.
  • ✅ 觉得影响编译器效率的, 那这个泛型不加最好. 零开销. (抬杠谁不会.

你真不会。要真杠，我直接就黑所有静态语言和静态类型语言都是垃圾了（又不是没黑过）。

只是现在看还不值得你这样层次的用户科普。

关于 <> 正统概念?

  • ✅ 你想多了. 谁更正统, 一点都不重要. (正统的东西多了. 没人用, 有卵用?

你表现得至少有显然认为 <> 是正统的嫌疑，否则为什么要拿一堆用 <> 的语言来举例？你显然没表现出你知道这种设计的历史，那么你有排除这些语言如此设计不就是在跟风吗？这样软弱无力的手法，比被你批判的 Go 高哪去了？

  • ✅ 至于学院派 vs 工业级 谁更笑话, 你开心就好. 张口就来 毒害的不只是个..., 毫无营养的评论.

其实看你不懂 <> 的来源，没表示你接受了常识科普，也没正面反对我说的事实判断有问题，我就够判断你算是典型“工业界受害者”了。

这样的见识还自我感觉良好钦定啥叫“毫无营养”，越来越让我找到婊谭×党的手感了，你开心就好。

说白了，我会在不见经传的地方堆科普草稿，也就是看在你的“我也不会删帖. 太拿自己当回事...”口气上。希望你不会反悔。

FrankHB commented 2 years ago

💢 关于multiple values:

  • ✅ 这里对 multiple values 的讨论.
  • ✅ 仅仅是为了回应 go 官方不使用<> 来实现泛型, 找的借口是 <>会和 multiple values 语义冲突.
  • ✅ 你作为不写 go 的, 根本不知道如上在争论什么. 就别凑热闹了
  • ✅ 隔空发评论. 很无聊. 自己立靶子, 自己喷? (令人发笑...
  • ✅ multiple values, 这种不值得讨论的特性. 都能让你高潮? 尿点有点低.

你确实不知道我为什么要在这里批斗一番，那么我解释一下：有人传播你的煋观点。

我很没兴趣搞一言堂，但是容忍一些比较离谱的笑话而没有不同观点发声，那就是另外的一边倒了。别误会，我对你搞 Go 毫无波澜（甚至还想笑）。尽管你要挑 Go 的事我周围的大家其实普遍都喜闻乐见（不管是转发的还是评论的），但是你要口嗨一些跨编程语言的话题，夹带私货散播不成熟观点还不打算让人纠正，那就是碍到我了。这跟遇到民科的反应是类似的。

正好 GitHub 直接方便评论，那就省得我找转发来源澄清了。

至于 Scheme.

  • ✅ 我也写过 Scheme. 秀语言没意思. 掌握鄙视链制高点? 然后呢? 冷不冷.
  • ✅ go/rust/dart/python/zig/c/c++/java/ 我都在生产中大量写过, 语法特性集, 见得多了. 有什么好秀的? 这么村?
  • ✅ 语言官司, 很无聊.
  • ✅ 想好好讨论就好好讨论. 不想讨论, 来阴阳怪气(自立靶, 自己喷...). 想秀什么?

你有改进过一个现有的工业语言么？

你有针对过语言 spec 二次开发 derive 出新语言么？

术业有专攻，我也不排斥非专业的讨论；但是一朝词穷找不到技术话题可以攻讦，光想着转移话题掩饰自己对该领域问题没什么理解，乃至一个“无聊”来贬低自己不知道的东西，就别想着还能自信“不值得讨论的特性”“高潮”这样的说法有啥逻辑能支持了。

还是说，你对别人把你当小朋友欺负有快感吗？

hhstore commented 2 years ago

懒得引了.

收束本篇博客主要论点:

如果你对1, 2 无异议. 那就没什么好讨论的.

光想着转移话题掩饰自己对该领域问题没什么理解.

别人把你当小朋友欺负有快感吗？

"民科"帽子:

PS:

FrankHB commented 2 years ago

懒得引了.

  • 需要说明一下. 你只是在引申话题 + 自己跟自己辩论. 我没精力跟你纠缠.
  • 碰巧回复你. 是因为当前, 我正好在写 blog.

我能理解你这样的心理，但是你回复表现得可不是这样。口嫌体正直。

我建议，你若认为你没问题，也不需多费口舌。读者自有判断。

收束本篇博客主要论点:

✅ 1. go 使用 [T] 作为泛型实现, 是很糟糕的方案. ✅ 2. go 官方拒绝使用 <T> 来实现泛型, 理由是和 multiple values 语义冲突 + 实现困难. - 为此列举 c++/rust/ 等其他主流语言 <T> 实现, 用以反驳. - 后续更新 vlang 的 泛型 <T> 实现方案, 再次佐证. ✅ 3. 其他讨论, 主要是 go 官方对社区提案的双标态度.

如果你对1, 2 无异议. 那就没什么好讨论的.

1.2.3. 都没异议。

但是我需要指出，你上面说的内容完全没明确 2. 的逻辑。

  • ✅ 我只是接着你的评论, 指出你在"自己立靶子, 自己喷".

所以这里不要怪人立靶子，是你的内容过于跳脱让人无法正确理解你的意思。

我建议你把上面在突然转进 <> 前写清楚理由。

  • ✅ 我没有兴趣和你讨论 "你自己立的观点".

别人把你当小朋友欺负有快感吗？

  • ✅ 写了10多年代码, 被你装到了. 你开心就好.

……我还写了 20 多年代码呢。这需要反复强调么。

  • ✅ 既然你懂术业有专攻, 你想跟我装什么? 换个角度, 我要装逼的地方. 你可能完全不懂.

看来暗示无效。那么直接提醒你，你完全可以对不懂的内容搁置不置可否当作台阶（而不是强行评论适得其反），反正我还没 low 到一个劲对没异议的内容复读或者揭外行短取乐。

退一步讲，我能从容地随便放 ALGOL-like 用户的地图炮，有必要针对你么。

  • ✅ 你哪只眼睛看见我吹全知全能了? 看别人转我的博客, 不爽? 来碰瓷?

我不理解你的思路的跳跃性。

对博客我也没兴趣，会需要评论的只是内容。

hhstore commented 2 years ago

免回:

FrankHB commented 2 years ago

编辑了嘛……那加点回应。

懒得引了.

  • 需要说明一下. 你只是在引申话题 + 自己跟自己辩论. 我没精力跟你纠缠.
  • 碰巧回复你. 是因为当前, 我正好在写 blog.

这边碰巧看到内容，是因为中间在等编译。

  • ✅ 不回应, 就让这种臭傻逼装到了. 回应, 就要跟这种臭傻逼没完没了纠缠.

愿意这样小人之心那自便。

  • ✅ 我虽然不做 PL 研究, 但是基本的设计, 你想跟我装, 还嫩. 你跟我扯的这些屁话, 我是懒得回(水平太低... 等我有时间专门写一篇博客.

写完了通知一下？

"民科"帽子:

  • ✅ 这些毒害的不只是个别语言而几乎是大半个工业界的用户, 这种暴论, 别删, 笑死了.

这种也好意思当暴论，见识真少。

  • ✅ 我寻思来了位比王垠还秀的大神.

不要把视野停留在博客圈，真的。

另外客观来说你比王垠有一点像样：能直接评论，不用我偶尔另外引用某些扯蛋观点消除影响了，局域性更好点。

  • ✅ 至于对反驳代码可读性以及其他几大段屁话, 别删.

你一天认为这是屁话，你就一天有被我黑的基本资格。直接罪状是口嗨“可读性”。

虽然到此为止你在这里的观点不明确到只是和谭×用户一样的地图炮炮灰。

PS:

  • ✅ 找个厂吧.

又没法让人理解你的思路了。这样写博客不会有问题么？

hhstore commented 2 years ago

别回我了.

FrankHB commented 2 years ago
  • ✅ 你对1,2,3都没疑问.
  • ✅ 跑过来自言自语. 还要说什么?

好小子，我说对后面回复的几点没疑问，但是我也说了一开始上面根本没写明白 2. 的逻辑，这还不准人说了？

  • ✅ 你爱放地图炮, 跟我有什么关系? 谁在意你的观点?(都懒得评论了, 还不懂?

提醒想躲都躲不开就投降吧……有人非得觉得自己血条厚那就真不关我事了。

谁在意我的观点这件事，这里有谁能说了算么？

  • ✅ 写了 20 多年代码, 就这水平? 就这理解力? (思路跳跃性, 你可以继续立靶子啊... 我不接...

不说了，让群众评价吧……

免回:

  • ✅ 我在写新的 blog. 没空跟你扯犊子.
  • ✅ 谁是谁非. 阅读者, 自己分辨就好.

写不清楚内容，让读者产生重大误解，以及误解读者的评论，这算是暴露博客作者基本素质的核心问题了吧？

还“免回”？行，那就当挂给其他读者看的。我无意 at 另行通知。

rendawudi commented 2 years ago

先不提博客作者的行为吧

只说说作者认为go社区的"双标"

个人觉得将心比心来说，如果我手上只有十几号人来开发和管理一个项目，这个项目有很多用户，用户会提各种各样的想法，但我手上只有这么些人，项目用的人有很多，历史包袱也很重，那么我只能坚持走一个大的方向，走这个项目的核心特色，用户提的想法肯定有好的，但绝大部分都是比较少见的场景的，同时，如果一个用户提了一个不错的idea被忽略了，那很正常，因为每个人都觉得自己的想法应该被尊重，但我手上的人精力有限；这个时候，我的项目组开发人员有了相同的idea，这个时候项目组开发人员的优先级肯定最高，因为他们是开发人员，他们更懂，虽然他们有自己的局限性，但从管理成本来说，这是最优的，个人认为。

因为只有领导过一个组织才知道，要学会舍弃，要学会给事情和想法定优先级。一个用户或者一些用户提了想法，那我肯定十天半个月才看一下，因为我手上事很多，但我手下的人提了想法，那肯定第一时间关注并尝试解决

obe007 commented 2 years ago

add <> generics !!! Don't compromise again and again

PeterlitsZo commented 2 years ago

只有十几号人来开发和管理一个项目，这个项目有很多用户，用户会提各种各样的想法，但我手上只有这么些人，项目用的人有很多，历史包袱也很重，那么我只能坚持走一个大的方向，走这个项目的核心特色，用户提的想法肯定有好的，但绝大部分都是比较少见的场景的，同时，如果一个用户提了一个不错的idea被忽略了，那很正常，因为每个人都觉得自己的想法应该被尊重，但我手上的人精力有限；这个时候，我的项目组开发人员有了相同的idea，这个时候项目组开发人员的优先级肯定最高，因为他们是开发人员，他们更懂，虽然他们有自己

但是不能双标啊。社区想要的一律忽略，Google 自己想要的加急处理，这算啥社区啊...... Go 的社区文化，个人感觉是所有开源社区里氛围最糟糕的，拥簇者一个劲跪舔 core team......

hhstore commented 2 years ago

大量 go项目 正在/已经 被 Rust 重写掉:

rendawudi commented 2 years ago

只有十几号人来开发和管理一个项目，这个项目有很多用户，用户会提各种各样的想法，但我手上只有这么些人，项目用的人有很多，历史包袱也很重，那么我只能坚持走一个大的方向，走这个项目的核心特色，用户提的想法肯定有好的，但绝大部分都是比较少见的场景的，同时，如果一个用户提了一个不错的idea被忽略了，那很正常，因为每个人都觉得自己的想法应该被尊重，但我手上的人精力有限；这个时候，我的项目组开发人员有了相同的idea，这个时候项目组开发人员的优先级肯定最高，因为他们是开发人员，他们更懂，虽然他们有自己

但是不能双标啊。社区想要的一律忽略，Google 自己想要的加急处理，这算啥社区啊...... Go 的社区文化，个人感觉是所有开源社区里氛围最糟糕的，拥簇者一个劲跪舔 core team......

不知道是不是个例，还是说真的有数据说明全部都忽略，自己想要的换哪个组织都是优先处理。其他的不做评价

Gaojianli commented 1 year ago

我觉得没啥大问题，人家的语言叫什么，叫"Google"，所以人家需要的自然是优先的。本来就是面向内部需求的，他只是碰巧开源出来用给你用而已，大公司开源的产品一贯如此。

PeterlitsZo commented 1 year ago

我觉得没啥大问题，人家的语言叫什么，叫"Google"，所以人家需要的自然是优先的。本来就是面向内部需求的，他只是碰巧开源出来用给你用而已，大公司开源的产品一贯如此。

那就是伪开源嘛，开源不仅仅是把源码提供出来这么简单，还要社区的和睦交流，共同进步。

ch3n9w commented 1 year ago

刚看到作者说自己从不折叠评论，一滑下来折叠一堆可还行。

hhstore commented 1 year ago

刚看到作者说自己从不折叠评论，一滑下来折叠一堆可还行。

Tnze commented 1 year ago

这个社区确实病态。

最近很不爽两个事情

  1. 添加zero标志符的提案通过了又被撤回（都不知道为什么会通过，也不知道为什么会撤回）
  2. 不支持范型方法，相关讨论了几百楼，完全不见官方的影子。
0w0c commented 2 weeks ago

我觉得没啥大问题，人家的语言叫什么，叫"Google"，所以人家需要的自然是优先的。本来就是面向内部需求的，他只是碰巧开源出来用给你用而已，大公司开源的产品一贯如此。

那就是伪开源嘛，开源不仅仅是把源码提供出来这么简单，还要社区的和睦交流，共同进步。

开源==开放源代码 开源≠免费 开源≠接受PR 开源≠接受提议 开源≠开放社区 开源≠随意使用

“伪开源”本身就是个伪命题

Tnze commented 2 weeks ago

我觉得没啥大问题，人家的语言叫什么，叫"Google"，所以人家需要的自然是优先的。本来就是面向内部需求的，他只是碰巧开源出来用给你用而已，大公司开源的产品一贯如此。

那就是伪开源嘛，开源不仅仅是把源码提供出来这么简单，还要社区的和睦交流，共同进步。

开源==开放源代码

开源≠免费

开源≠接受PR

开源≠接受提议

开源≠开放社区

开源≠随意使用

“伪开源”本身就是个伪命题

这源开的忒窝囊