@penzi 和微服务无关，这种规模的分布式系统出现全球崩溃，本身已经说明问题了

整个流程只要有一个阶段发挥作用都不会全球崩溃吧。
设计：不评估数据库权限问题？
开发：谁让你用 unwrap 的？
测试：非法配置文件 bug 很难测出来？
上线：你灰度呢？直接改全球？
故障：雪崩不做防御？

这么看来 cloudflare 也挺草台的

只能说匪夷所思。
cloudflare 没有灰度机制吗？一下子把全球的权限和配置全改掉？测试呢？这很难测出来吗？
设计时没预料到数据库权限问题？雪崩不做防御？
这下真得屋千蟑/海恩法则了。

当你对你的内存安全知识很自信时，想想心脏滴血和永恒之蓝，你觉得你比 OpenSSL 的人厉害还是比 Windows 的人厉害？（狗头

有人已经在用 Rust 赚钱了，有人还在打语言口水仗。

很多人学不会 Rust 完全是没有放下包袱，还在用其他语言的思维硬扭，那当然效率提不上去。
反而一些学生上手 Rust 就飞快，就算现在有 AI 辅助，也能看出人和人之间的学习能力确实有区别。

话说回来，重写旧项目总是有目标的，你的目标可以是提升性能、降低维护成本、练习新技术栈、吸引开源贡献等等，但不能是跟风。评估一下你是否能在合理的耗时内达成项目目标，就知道该不该重写了。

有个顶着神风特攻队昵称的老外问 "Are you chineese spies?"，被点了 24 个倒赞，难绷
https://github.com/rustfs/rustfs/issues/15

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

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

包管理器打来打去，架不住别人发论文还是用 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 的性能。

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