“背锅”是一种非常糟糕的管理策略，会使员工倾向于掩盖可能发生的错误

有 bug ？不用修，想办法不让人知道就行

@araraloren 怎么没关系？编译时间变长，开发体验就下降了。原本 O(n) 跑完 parse 部分，现在可能要 O(n ^ 3)，能忍？！
前段时间 cloudflare 被一个正则匹配搞挂一大片，你不要以为 parser / recognizer 真的是什么“自动化流水线模块”，文法不好处理，parser 分分钟榨干你的 CPU ！
C++之前有近十年的时间，是不能连写 >> 的，一定要加个空格写成 > >。好处理的话，从一开始就不会出现这种问题。何况，() 和 <>，真的能分出谁方便谁不方便？

让测试学会用开发者工具，看后端请求的返回对不对，看页面和后端的数据是不是一致。
再说了，同时指派一个后端一个前端不就行了。

能用三年不错了，鼠标本来就有最大点击次数，物理结构会变形损坏的，没什么意外的

刑法第一百六十三条了解一下

@LokiSharp 主要是还没有分代，有了分代，GC 可以少消耗一点 CPU。而且主要目的是降低延迟，而不是降低内存占用，现在 go 的 GC 的暂停时间可以低于 0.5ms

@LokiSharp 看 busy 指标，这几个程序里 go 都比 java 高，就是 GC 的消耗多

@LokiSharp regex-redux 慢，是因为用到了 cgo。binary trees 慢，是因为 go 的 GC 比 java 的更频繁，消耗 cpu 更多。基本上 GC 多的程序，go 都比 java 慢，因为 go 偏向低延迟，而不是高吞吐

为什么你要这样做？

java 是虚拟机，天然就多占内存，再加上没有值类型，很多数据结构都不是紧凑布局的

.net core 同理

go 的自动 GC 相对于非自动 GC，多使用的内存主要是 GC bitmap，这部分是 2bit 对应堆里的 64bit，也就是 512GB 的堆全分配满的话，GC bitmap 就会有 16GB，三十二分之一的 overhead。

另外，GC 算法不同，占内存也会不同。会复制对象的 GC，在复制过程里就需要占用额外的内存。java 的 CMS, G1 都是 copying GC。zgc 暂时不做复制。

还有个影响因素是向 os 申请页和释放页回 os 的策略。如果虚拟机选择一开始就申请很大的内存，那占用自然高。释放慢，也会高。go 不会预先申请很大的内存，释放页也比较积极，所以内存占用相对就低。

@abcbuzhiming 分布式仓库就没有信任和稳定了？ maven 就不会倒闭？ npm 还被投过毒，中央仓库就一定稳定和值得信任，我认为是假命题。github 也没有浪费谁的时间精力吧？我用 github 做仓库也没有啥折腾的。

go 的仓库模式，就等于 git、hg 等版本管理工具的模式，你不习惯可以不用，但我们用得好好的。

@liulaomo c++没有 concept 做约束的话，可能展开很多层才抛错，错误信息就很难理解了。contract 是和 concept 很像的