golang性能比C和Cpp差好遠，尤其在非x86平台，跟本不是宣傳的那

dong总你们质量控制不行啊，说说你们采用了啥方法监督控制质量，我们看看能不能给你提提建议

【 在 wdong (万事休) 的大作中提到: 】
: 说得太对了。我带了好几个人了，从来不敢让他们插手我的C++项目。
: 只要引入一个好玩点的bug就够我受的了。
: 好在现在有python。

C++的所谓质量控制就是阉割

【 在 bruklyn (我爱布鲁克林) 的大作中提到: 】
: 让你笑死我了，你们厂完全不用C++所以你怕C++成了这样吧，C++没那么可怕，程序开
: 发都有质量控制
: C这种可读性差的一个牛人单干有可能，比如Linus

stl只是一个general的实现，目的不是cover所有specific的问题

【 在 magagop (magagop) 的大作中提到: 】
: 你說的應該是c++03 stl性能不好，老黃曆了，現在正在改變。
: c++11和c++03是兩種語言，c++20和c++11/03比則是第三種語言。

看了前面大拿的发言，感觉是给不愿意学C++的C老帮菜们用的
跟智商没关系

【 在 minquan (三民主义) 的大作中提到: 】
: golang的初衷就是智商高于80%分位低于95%分位的较优秀人才能编利索，而且在这个档
: 秒杀竞争品种，例如python
: 至于你说的极限速度不如C++
: 不是废话吗？
: C++几个能用好，几个能继承前任代码？

这么说吧，火药危险吧，照样生产吧，你听说军工厂经常爆炸么？

【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: C++的所谓质量控制就是阉割

C++等于让全厂工人随便碰火药

【 在 bruklyn (我爱布鲁克林) 的大作中提到: 】
: 这么说吧，火药危险吧，照样生产吧，你听说军工厂经常爆炸么？

同意。
Golang能在像uber这样管理混乱的公司一统江湖，正是因为它在开发效率和运营效率之间取得了完美的平衡，相比于其它语言有巨大的优势。
不知道两个月过去，楼主有没有认清golang是新一代公司主要backend语言的现实，别
再为c++招魂了。公司的技术骨干做决定时会考虑商业需求，在什么语言合适的问题上
绝对有判断力。

【 在 silverhawk (silverhawk) 的大作中提到: 】
: 不知道三倍这个benchmark哪里来的，每个人实现不一样，我没有做过C# 对golang的对
: 比，不过网上有很多，随便找一个https://hackernoon.com/go-vs-net-core-in-
terms
: -of-http-performance-7535a61b67b8，可以试一下，
: 我觉得其实你可以改变mindset，你对底层了解，为啥不想着去提升golang性能，这样
: impact会大得多，如果你假设别家都是不知道golang比CPP性能不如，误入golang，恐
: 怕也太低估这么多上golang公司的技术能力和项目判断了。相反，如果golang性能不如
: CPP下还这么收欢迎，岂不是Golang性能提升之后更大有可图，所以做这个的话，
: impact比你只是比较CPP和golang大多了。
: 当然项目选择语言，各家各个项目组，历史现实都不一样，不好判断

先说需求，你要干什么，然后再比较工具。我小时候经常比较C和Pascal，那时候比较
的点跟现在可不一样。既然C++什么都能做为啥要用别的呢？说开发效率，都是copy自
己积累了几十年的代码库，智能指针也能省很多事。要说公司雇了一批新手，那就没办法了，我永远不会钻进这样的新手组。

最近忙于写作，路过打一把酱油。

招魂也谈不上。

遇到性能攸关的项目，还是得上c++。golang在k8s算得上一统江湖吧，envoy还是得用c++写。

【 在 fantasist (一) 的大作中提到: 】
: 同意。
: Golang能在像uber这样管理混乱的公司一统江湖，正是因为它在开发效率和运营效率之
: 间取得了完美的平衡，相比于其它语言有巨大的优势。
: 不知道两个月过去，楼主有没有认清golang是新一代公司主要backend语言的现实，别
: 再为c++招魂了。公司的技术骨干做决定时会考虑商业需求，在什么语言合适的问题上
: 绝对有判断力。
: terms

哪种情况叫性能攸关？我没听说过哪家公司的golang backend service因为性能问题只好用c++重写。一些要挖掘单机最后一丝性能的项目用c++很正常，没人说go能完全取而代之，但只要靠堆机器scale up，go就有机会。看待go的时候要认识到以下两点才能不偏激：
1. Golang的性能完全胜任足够复杂的高并发后端系统，比如uber的车辆调度和twitch
的直播评论。
2. 新公司后端选择了golang是因为它好用，不是因为它们盲目跟风。

【 在 PaiMei (白眉) 的大作中提到: 】
: 招魂也谈不上。
: 遇到性能攸关的项目，还是得上c++。golang在k8s算得上一统江湖吧，envoy还是得
用c
: ++写。

我说的envy就是性能攸关啊。
你要搞个service mesh，每个反向代理的延迟、吞吐量都差30+%，整套服务下来还不得要命。
【 在 fantasist (一) 的大作中提到: 】
: 哪种情况叫性能攸关？我没听说过哪家公司的golang backend service因为性能问题只
: 好用c++重写。一些要挖掘单机最后一丝性能的项目用c++很正常，没人说go能完全取而
: 代之，但只要靠堆机器scale up，go就有机会。看待go的时候要认识到以下两点才能不
: 偏激：
: 1. Golang的性能完全胜任足够复杂的高并发后端系统，比如uber的车辆调度和
twitch
: 的直播评论。
: 2. 新公司后端选择了golang是因为它好用，不是因为它们盲目跟风。
: 用c

公司飞速发展的初级阶段需要糙快猛，就用简单容易上手的语言。等做大之后有钱有闲了，再招牛人们手撸C/C++提高performance，变相节省data center开支。FB不就是这
样么？

【 在 fantasist (一) 的大作中提到: 】
: 哪种情况叫性能攸关？我没听说过哪家公司的golang backend service因为性能问题只
: 好用c++重写。一些要挖掘单机最后一丝性能的项目用c++很正常，没人说go能完全取而
: 代之，但只要靠堆机器scale up，go就有机会。看待go的时候要认识到以下两点才能不
: 偏激：
: 1. Golang的性能完全胜任足够复杂的高并发后端系统，比如uber的车辆调度和
twitch
: 的直播评论。
: 2. 新公司后端选择了golang是因为它好用，不是因为它们盲目跟风。
: 用c

提高perf节省dc cost主要并不是依靠语言。架构复杂的分布式系统里，用c++重写几个component，效率就能高10倍，不觉得这种说法是天方夜谭吗。我的经验是，fb这样的
大公司花了最多精力在这些优化上：
1.减少硬件浪费。有的service只需要3台机器，却配置了10台，需要一系列capacity管理工具通过系统load动态调整，并把service放进container。
2.减少软件浪费。比如某组的ranking engineer测试新feature后发现没有用但忘记删
除，不断生成的data占用很多资源，清除这些每天能节省PB级的存储。
3.追踪regression。在php repo里，每个diff都有可能造成性能问题，需要一个系统自动锁定谁是trouble maker。
4.提供各种工具让developer的工作更有效率。人工成本可不比服务器成本少。

【 在 pxu (又呱噪又抠门还偷老婆钱) 的大作中提到: 】
: 公司飞速发展的初级阶段需要糙快猛，就用简单容易上手的语言。等做大之后有钱有闲
: 了，再招牛人们手撸C/C++提高performance，变相节省data center开支。FB不就是这
: 样么？
: twitch

Scylla DB就比Cassandra的throughput大很多倍：
https://www.scylladb.com/product/benchmarks/

【 在 fantasist (一) 的大作中提到: 】
: 提高perf节省dc cost主要并不是依靠语言。架构复杂的分布式系统里，用c++重写几个
: component，效率就能高10倍，不觉得这种说法是天方夜谭吗。我的经验是，fb这样的
: 大公司花了最多精力在这些优化上：
: 1.减少硬件浪费。有的service只需要3台机器，却配置了10台，需要一系列capacity管
: 理工具通过系统load动态调整，并把service放进container。
: 2.减少软件浪费。比如某组的ranking engineer测试新feature后发现没有用但忘记删
: 除，不断生成的data占用很多资源，清除这些每天能节省PB级的存储。
: 3.追踪regression。在php repo里，每个diff都有可能造成性能问题，需要一个系统自
: 动锁定谁是trouble maker。
: 4.提供各种工具让developer的工作更有效率。人工成本可不比服务器成本少。

我觉得你是不是没有get到，大厂一个single service经常使用达到万台机器
用不用C++明显要考虑（节省的运行成本（电费、硬件开销）- 增加的软件开发成本）
如果使用的机器数量是n，前者是O(n)，后者是O(c)

【 在 fantasist (一) 的大作中提到: 】
: 提高perf节省dc cost主要并不是依靠语言。架构复杂的分布式系统里，用c++重写几个
: component，效率就能高10倍，不觉得这种说法是天方夜谭吗。我的经验是，fb这样的
: 大公司花了最多精力在这些优化上：
: 1.减少硬件浪费。有的service只需要3台机器，却配置了10台，需要一系列capacity管
: 理工具通过系统load动态调整，并把service放进container。
: 2.减少软件浪费。比如某组的ranking engineer测试新feature后发现没有用但忘记删
: 除，不断生成的data占用很多资源，清除这些每天能节省PB级的存储。
: 3.追踪regression。在php repo里，每个diff都有可能造成性能问题，需要一个系统自
: 动锁定谁是trouble maker。
: 4.提供各种工具让developer的工作更有效率。人工成本可不比服务器成本少。

天哪，是啥让你觉得后者是O(c)的。跑10台机器上的service，跟跑10000台机器上的
service，开发成本能一样吗？大厂service各种耦合，重写一个service往往解决不了
什么问题，另外还有迁移测试等成本。
我前边回的几个帖，用手机好不容易打了那么多字，就是希望大家能意识到软件最终是要为公司的business服务的，语言的性能只是一个指标，往往还不是决定性因素，看问题的时候要多考虑几个维度。感觉对牛弹琴了。。。
【 在 bruklyn (我爱布鲁克林) 的大作中提到: 】
: 我觉得你是不是没有get到，大厂一个single service经常使用达到万台机器
: 用不用C++明显要考虑（节省的运行成本（电费、硬件开销）- 增加的软件开发成本）
: 如果使用的机器数量是n，前者是O(n)，后者是O(c)

不是O(c)难道是O(n)？只要你承认比O(n)小，再回去看看我的帖子

【 在 fantasist (一) 的大作中提到: 】
: 天哪，是啥让你觉得后者是O(c)的。跑10台机器上的service，跟跑10000台机器上的: service，开发成本能一样吗？大厂service各种耦合，重写一个service往往解决不了
: 什么问题，另外还有迁移测试等成本。
: 我前边回的几个帖，用手机好不容易打了那么多字，就是希望大家能意识到软件最终是
: 要为公司的business服务的，语言的性能只是一个指标，往往还不是决定性因素，看问
: 题的时候要多考虑几个维度。感觉对牛弹琴了。。。

多说无益，你自己来大厂体验一下就知道了
【 在 bruklyn (我爱布鲁克林) 的大作中提到: 】
: 不是O(c)难道是O(n)？

编程语言性能在绝大部分环境下不起决定性作用，2018年了，这个不需要你再来安利吧。你也不要觉得自己不是牛还会弹琴。

没记错的话你就是Facebook的吧？你厂狂用C++你跑来和大家拼命讲语言性能不重要，
大家觉得你有点分裂而已。

【 在 fantasist (一) 的大作中提到: 】
: 天哪，是啥让你觉得后者是O(c)的。跑10台机器上的service，跟跑10000台机器上的: service，开发成本能一样吗？大厂service各种耦合，重写一个service往往解决不了
: 什么问题，另外还有迁移测试等成本。
: 我前边回的几个帖，用手机好不容易打了那么多字，就是希望大家能意识到软件最终是
: 要为公司的business服务的，语言的性能只是一个指标，往往还不是决定性因素，看问
: 题的时候要多考虑几个维度。感觉对牛弹琴了。。。

大多数golang的service跑在不超过几个，十几个机器上。我好奇golang跑的最大的
service是什么？有超过一千台server的golang service么？我想围观一下

你既同意"编程语言性能在绝大部分环境下不起决定性作用"，又反对“语言性能不重要”，到底谁分裂了？
另外声明一下，我明确把话题限定在golang的性能在大部分分布式系统中不是瓶颈，请不要曲解我的意思。
再谈谈fb backend狂用c++的设定，这是个很有意思的话题。我认为主要是由于早期招
的人多是acm选手和从google挖的c++程序员，大多数系统的原型是c++，很难改变了。
与G家闲人众多不同，F的dev infra团队没有足够的资源去支持其它语言，比如golang
的支持是两三个dev出于兴趣用业余时间一点点搞起来的。16年后端build system从
fbmake改成buck，golang由于不是主流语言，用它开发只能一步步地把坑踩过去。
thrift的支持不好，跟其它service通信都有问题，还谈什么。我写的一个需要cgo的
side project直接无法编译，只好放弃。这恰好印证了我之前说的，legacy code太多
无法重写大公司只好沿着一条道走到黑的理论。G家dev support资源应该是很多的，所以后端百花齐放，可以选择c++, java和go，甚至更多小众语言进行开发。
【 在 helpme (名虚胖字满肥) 的大作中提到: 】
: 编程语言性能在绝大部分环境下不起决定性作用，2018年了，这个不需要你再来安利吧
: 。你也不要觉得自己不是牛还会弹琴。
: 没记错的话你就是Facebook的吧？你厂狂用C++你跑来和大家拼命讲语言性能不重要，
: 大家觉得你有点分裂而已。

FB早期不是纯php吗？赵海平也不是狗家的前员工，写hiphop就是图C++的performance。

【 在 fantasist (一) 的大作中提到: 】
: 你既同意"编程语言性能在绝大部分环境下不起决定性作用"，又反对“语言性能不重要
: ”，到底谁分裂了？
: 另外声明一下，我明确把话题限定在golang的性能在大部分分布式系统中不是瓶颈，请
: 不要曲解我的意思。
: 再谈谈fb backend狂用c++的设定，这是个很有意思的话题。我认为主要是由于早期招
: 的人多是acm选手和从google挖的c++程序员，大多数系统的原型是c++，很难改变了。
: 与G家闲人众多不同，F的dev infra团队没有足够的资源去支持其它语言，比如
golang
: 的支持是两三个dev出于兴趣用业余时间一点点搞起来的。16年后端build system从
: fbmake改成buck，golang由于不是主流语言，用它开发只能一步步地把坑踩过去。
: thrift的支持不好，跟其它service通信都有问题，还谈什么。我写的一个需要cgo的: ...................

看完两个高楼，收获很大
【 在 pxu (又呱噪又抠门还偷老婆钱) 的大作中提到: 】
: FB早期不是纯php吗？赵海平也不是狗家的前员工，写hiphop就是图C++的
performance。
: golang