支付宝能默认隐藏付款码，微信没找到设置

及时备份或自建吧，仓库放在自己手里才能安心

包管理器打来打去，架不住别人发论文还是用 requirements.txt ，真是互相恶心。
python 生态多年顽疾，短时间治不好的。

@FoxRiverMan 一眼 deepseek 生成内容，这玩意已经能被人类识别了

@lesismal #103
把你自己的经验和成果展示出来，比什么都强。反驳别人挺浪费时间的。

@lesismal #101
唉，如果有人会因为这种说法去黑 Go ，这不是你我能改变的

@lesismal #94
> at 你是因为 #63 说资历的问题

那我明确一下，#63 是指向 #60 。无意冒犯你。

> 如果因为我的观点就导致了你带个人看法，那我表示抱歉
> 但我建议不要这样、这相当于丢掉了自己的理性判断，没必要

在别的评论区我还是会保持避免引战，给出什么语言适合什么场景的评价，而不会一概而论哪个语言就是优秀。
即便有人说 rust 有什么问题，只要客观存在，我也会同意。
Go 1.0 已经 13 年了，不能论质量就是成熟，论问题就是年轻。

> 严格来讲不是否定，但在宽泛的社交语境，这约等于否定、并且实际效果就是偏否定的
> 我没有要求任何人给出优秀评价，而是反驳这些人，为什么如此了还不能称为优秀。

没说优秀=否定优秀=需要反驳，我觉得你不需要坚持这个链条去反驳任何人。
讲一讲 Go 的相对优势适用于哪些场景，分享你自己的实际经验，已经足够了。

@lesismal #85

> 客观的 gopher 就是这样做的，包括我自己
我并不认为要求别人给出“优秀”的评价是一种客观的做法。

> 自己具有一定水平和判断力的人，也不会因为别人的态度就站在了反面
本来给出正面评价、想避免引战的人，现在会附带一些个人看法。

1. Go 至今没有官方的全功能版本管理器，升级工具链得手动来或者借助第三方工具。
2. unused import 是 error 不是 warning ，想注释掉某些使用看看效果，还得跟着改 import 。
3. "nil" 不是 nil 。
4. 默认零值，零值和空值的区分问题。
5. 大小写访问控制，导致结构体序列化要为每个字段写 json 重命名。
6. 时间格式串 "2006-01-02 15:04:05"，最迷惑的设计之一。
7. 缺少 enum 导致 switch case 无法检查有没有覆盖所有情况。
8. 循环中使用 defer 。

你也不用告诉我解法，这些坑我都知道。只是想说，在体验过这些后实在是不能称其为“优秀”。

@lesismal #82
那我只能说，批判别人“没说优秀”的行为只会把别人推向反面了。
优不优秀是主观看法，不符合我的需要和审美，就是不优秀。这是没法客观论证的。
能客观论证的是哪些方便做，哪些可以做，哪些做不了。

@lesismal #77
你不能按“没说优秀就是否定优秀”来判定，或者对“不懂得独立思考”的人的影响来判定，不然每次写回复都得叠
甲，很累……
该用 go 的时候我也会用，但体验到 go 的众多拍脑袋设计之后，也确实说不出口它有多优秀，只能说是个实用语言。
再加上社区提案爱答不理，谷歌需求立马安排，这种行为实在是难绷，可能需要微软出个 go# 给他们上上压力。

@lesismal #68
所谓 Go 是优秀还是平庸，一般是从语言设计的角度衡量。而 Go 在语言特性上有意取舍，有人称之为简洁，有人称之为简陋，可以找到大量相关评价，甚至长年累月的“语言战”。
Go 并不完美，在语言特性和工程实践上也有不少坑。隔壁刚好有人提问 https://v2ex.com/t/1117750 ，作为一个新鲜例子。

引用官方回复
> No single language is perfect for every task
TS 团队官方的意思也是以契合度为主要原因，前面提的优点是契合度的论据。换一个任务场景就不一定是优点了，例如不可能拿 Go 去重写 LLVM 。而且 Go 的进程内 JS 互操作性和 WASM 支持也是很多人提出的疑问。

提契合度不等于忽视优点，而是划分决定性因素和非决定性因素。不然人家 C# 用户要问了，C# 也很优秀，为什么不选自家产品？

最后叠甲，以上仅为个人对此事的看法，不代表任何选型意见，无意冒犯任何人。

资历只能影响一个人说话的份量，但不会自动堵上别人的嘴，望周知

人家想找个能支持 typescript 旧代码库风格的原生语言，把逻辑原原本本地**移植**过去，选 Go 很正常。
如果要彻底**重写**所有架构，人家说了，用其他语言也合适。而且未必达不到 Go 的性能。

根据任务目标进行决策没什么毛病，想参考的话，看看你的任务目标是否一样。

@james122333
有力人士施压这个无法证明也无法证伪，上次他们开除俄罗斯开发者就没承认到底为什么，不能排除美国信创影响。

确实有内核开发者提到裁剪 Rust 的问题，目前的共识看起来是要做到完全剔除 Rust 也可以编译，避免影响纯 C 的用户。不过从纯技术角度看，Linux 内核第二语言是一个有意义的探索。

@kk2syc 你看错了，Linus 是回应 Christoph Hellwig 。硬要比喻也是菜刀研发者无权管理菜刀生产线开工还是停工。同一个工厂，不同分工。

@zzz22333 这件事是有维护者反对一个 Linux 主线中的 Rust PR ，Linus 表示你这个 C 方面的维护者无权阻止合并……

Linus 的态度是明确反对 c++ 进内核，支持在内核驱动方面引入 Rust ，并且是合并到主线，不是 out of tree 。

不重要的账号用浏览器等同步服务。
敏感账号靠脑子硬背，忘了就重置密码再次硬背。