@EIJAM 怎么还在传这个烂梗。别的不说，这个实习生自己跑出来说叠一层空白 div 就会让硬件加速失效（并且微软之后立刻就修复了，可见只是自己的代码写的烂）也不知道是丢谁的人。

至于这个空白 div 的背后逻辑，我看这篇文章解释的应该差不多。https://medium.com/@jeremy.noring/did-google-cripple-edges-youtube-performance-ce5169d3e5f4

致于 Google 为何不会做这种事，我这么说吧，公司文化先不谈，Google 内部连 Windows 都基本找不着，谁去找 IE 的 bug 来减速 YouTube 。Google 也真没这么牛去找到这些 bug 。

@sgissb1 我赞成主要是看人，这个是没有任何疑问的，所以我的前提一定是合格的程序员。不过我理解你说的问题，你说的对，确实大多数情况下，性能问题是不会由切换语言而解决的，不存在因为我是 rust 写的所以它就更快更省内存。我自己在写 rust 的过程中也知道有些东西只是理论上会快一点，但是这些东西在 rust 里面都是没有任何心智成本的（不论是维护上还是实现上）。也确实有一些场景由于 rust 本身的很多特性使得我可以大胆地进行很多优化。

@nbndco 例子没仔细想，不一定 work ，可能要改成 `fn foo(arg: impl T + Send + Sync)` 更合理一点，但是意思是一样的。

@nbndco 忘了提抽象的问题了。

这些 over defensive 和 Ergonomics 本质上都是语言抽象能力弱，导致语义总是不清晰造成的。在 rust 里我可以写类似 `fn foo(arg: impl AsMut<dyn T + Send + Sync>)`来保证 thread safety 。这就使得我们可以在函数里避免所有无意义的锁（如果我们的类型不是 Send 和 Sync 的我们可以在调用的时候自己加上锁再传入就好了）。

在 C++里我就算放弃类型安全使用模版我都不知道该怎么实现这个函数。

@sgissb1 以上所有的东西，我都没谈 Ergonomics 。

其实这个对性能影响也是根本性的。语言功能弱带来两个问题，一是代码可重用度低，从而优秀的算法不方便抽象成库广泛使用，二是正确的写法可能太麻烦，就懒得实现了。

但是理论上这不是性能损耗，因为你总是可以实现的么。只不过 rust 可能就是一两行，C 可能就要自己写几百行。

@sgissb1

继承和多态都用不好的程序员完全不合格。我既然说了水平达到一定程度，这种入门的基础自然是已经完全理解并可以自然而然的应用的。我当然知道现在有些人自称程序员但是完全没入门，但是那个并不在考虑范围之内，rust 没有解决他们不会写正确的代码的问题，只是阻止了这些人写代码而已。

以下都假设是一个合格的程序员在写代码。

越简单就性能越好基本只对几百行的程序才可能为真（如果先不提 rust 的 zero cost abstraction 可能不会让代码变慢）。一旦代码复杂了之后，人脑能够理解并且不会发生错误的可能性太低了，必须要编译器来进行帮助。如果有些时候编译器帮助不了怎么办呢，只有两条路，要么就是写错误的代码，要么就是 over defensive （性能受损）。

我随便举两个例子，你既然对 C++比较熟悉，那么问：

1. 一个传入的指针，他的生命周期是什么？答案是，不知道，全靠文档和看源代码。

C++为了在语言层面上解决这个问题，只好加入 smart pointer ，但是并没有根本上解决这个问题，很多时候只是把所有的东西包在一个 rust 的 Arc<T>里了而已。

这带来两个问题：我们显然不能把一个传入的裸指针包进 shared_ptr 里，也就意味着所有的接口必须直接使用 shared_ptr ，即便某些情况下我们调用时事实上知道我们并不需要 shared_ptr （ enable_shared_from_this 我就不说了吧，基本给 shared_ptr 的正常使用判了死刑，说白了 smart pointer 除了 unique_ptr 以外其他的都完全没用）；第二，如果接口没有用 shared_ptr 怎么办呢，所有权如此的不清晰使得我们只能把传入的数据拷贝一份，这个性能损耗就是非常惊人的了。

以上这些美好的设计还是建立在调用者和被调用者都正确地根据严谨清晰地文档实现了周期管理的前提下的，毕竟写错了也只有 runtime 的时候不时的报 segment fault 或者 leak 连错都没有。这点显然 Mozilla 的程序员水平完全不行，项目规模一大就不会写代码了，gecko 的内存泄漏问题一直都很严重，只好写个 rust 出来给自己擦屁股。

2. 一个类是否 thread-safe ？答案是，不知道，全靠文档和看源代码。

看文档，如果文档说了那就可以确定（吗？）；如果文档没说，那么就只好去看源代码，如果没有源码，那就只能假设不 thread-safe 然后加锁了。为什么会这样呢？因为语言层面没有提供任何的机制来帮我们确定代码是否 thread-safe 。这个过程没必要的锁可能就不止一个了。没必要的锁可能发生在两层：1.类已经是 thread-safe 的了但我不知道； 2.虽然不是 thread-safe 但其实我们并没有任何 concurrent 的访问或者 mutable 的访问。

但是，老问题，以上这些美好的设计还是建立在调用者和被调用者都正确地根据严谨清晰地文档实现了 thread safety 的前提下。就算你今天是个优秀的程序员，通过仔细阅读代码确保了没有在一个 thread safe 的类访问再加一层锁，你有如何保证之后某个同事（甚至就是你自己）在修改这个类的时候把它改成不 thread-safe 的了呢？

我这几年写了一点 rust ，lifetime ，ownership 和 synchronization 基本都是我在 api 设计时候的本能反应了，依然还是会经常有各种编译器的错误，而且我看半天才能明白究竟哪里错了。

根本问题就出在，一旦代码复杂，人脑想要在 lifetime 和 synchronization 两个问题上想清楚不出错是不可能的，且不说你不可能通读所有代码并且不会想错任何东西，就说多人合作时大家各写各的改着改着你没动的代码就崩了。为了写出正确的代码，你只能 over defensive ，性能损耗随之而来。

通过 fakeip 可以拿到连接的域名，这样解析就可以正确地发生在代理服务器上

@sgissb1 理论上来说资源占用是水平问题，水平不行的人写 rust 也不会快。

但是如果水平到达一定程度的话，其实就涉及到一个语言特性的问题。

有的时候，项目一旦复杂，或者想要设计的很灵活，那很多问题就希望能够进行抽象，但是不同语言的抽象成本差距非常大。

像 rust 很多时候几乎是 zerocost 的抽象，使得我们几乎都不需要任何 Box 就可以实现非常灵活的功能。这在 C ，go 里面几乎无法想象，基本是原理上的不可能。在 C++里面，由于模版本身的限制，使得大规模的使用模版的开发维护难度非常高，在实际工程中几乎不可能，只能在极少数性能敏感的库中使用。

另外很多功能比如 Iterator ，使得一个自然设计的 API 在使用时就几乎不会产生不必要的性能损耗。这在其他语言中只是理论上可实现，可由于难度过大或者过于繁琐而没有任何人会去做。

这些都几乎没法通过开发者的水平来弥补。

@fishCatcher 第四部这样也是有剧情深度么……

烂的无法想象。

如果用一句话形容，就是格外接地气，坚决不耍帅。

打斗场景？随便找个地方就好。人物造型？反正衣服都穿着呢。剧情？我都不敢动脑思考。

最重要的特效？除了最后二十分钟的僵尸围城效果还算标准爆米花的及格水准之外，全片几乎没有任何有意义的特效了。虽然我还没懂为何我要在 matrix 里看僵尸围城。

为了能够让片子做到绝不耍帅，全片甚至没有一幕经典的偏绿调色！

浪费了两个多小时，甚至找不到一幕想要再看一遍。还不如回头把三部曲重看一遍。

非常严重的过度设计。



有人说这种东西需要组长决定，或者公司不是来让你学习的，反而不应该是考量因素。大家天天问怎么提升薪水，你天天就乖乖听组长分配的任务堆 CRUD ，其他不闻不问不学习，真的能加薪吗？

真正关键的是，你要解决什么问题，以及如何解决问题。

就你描述的情况本身，一个服务两个节点，看起来也不像是会有很大的增长的样子，那么就不存在 service mesh 的应用场景。也就是说，你没有解决任何问题，只是单纯的引入了一个新的（大）问题——设置管理维护 consul ，组长只是提醒你不要过度设计，也是有问题的，要是我就直接让你全撤了。你要意识到，你的实践一定是实践如何用 consul 解决问题，不是使用 consul ，你要用 consul 你自己搭个 k8s 就好了。

所以这样做就没有意义么，也不是。这就取决于你要解决什么问题。

你说你现在做的是一个微服务，那就意味着公司里有很多其他的微服务。你说你在使用 consul ，那就意味着公司现在并没有任何的 service mesh 方案，考虑到 consul 和 k8s 绑定之紧，我甚至可以猜测整个公司的服务部署都是完全独立各组自行管理的。这显然是一个错误的方案，缺乏正确微服务架构的特性。那么，要不要提升，要不要改，要不要用 consul ，我觉得是很值得考虑的。

有人肯定又要说这种事情推不动，大家都只想堆 CRUD 。那我也没啥可说的，这个时候我只能反省为何我会加入这种公司了。

@JeffGe 不是，如果引用的话就看不见内容。在群里基本大家都是把这个当回复用的

回复的微信还只能推送显示“你收到了一条微信消息”，连显示信息内容这一技术难关还尚未攻克。想要显示头像是不是苦难了点

@DogeFlyKite 可以的，iOS，Android，macOS 都可以直接用官方 API 屏蔽截图。

可以的，iOS，Android，macOS 都可以直接用官方 API 屏蔽截图。

@nonwill 这个二进制方式打开以后应该怎么样才能发现很多一致的地方啊……
当然欧路如果基于 goldendict 做桌面版开发似乎也是很有可能的

我有几点没搞明白：
1. 你是怎么知道欧路词典用了 goldendict 的代码的？我还专门下了个欧陆词典，属于那种非常典型的没有 acknowledgement 的国产软件（或者藏的实在太深，我已经把“账号”下面的所有东西都点了），虽然违反了无数 license 是肯定的，但是似乎没有任何理由就说他用了 goldendict 的代码吧。而且我看了一下 goldendict 的代码，原生也并不支持 iOS，mac 的编译方法也语焉不详，外加还有一大堆的依赖，似乎也是作为一个 app 而不是一个 lib 开发的。这种连 license 都弄不明白的公司真的有水平用这些代码做 iOS 开发么？真的比自己写效率要高么？
2. 我查了一下，欧路已经支持 ocr 了。也可能是我理解错了，因为我没用过欧路，而且这似乎也不是他们宣传中的主打功能。这个是欧路用你闭源前的代码完成的么？
3. 如果欧路真的违反 license 了难道不应该去起诉他么。不开玩笑，你写封信给 https://softwarefreedom.org ，把证据附上，他们直接和 apple 谈（事实上，如果你不是 copyright owner，只有 GPL 授权根本就上架不了 app store ）。先把欧路全下架了，整肃一下风气，不是对个人开发者最好的保护么。当然，我个人觉得即便是真有这个情况，你也应该先联系欧路让他们不再使用 gpl 的代码，而不是直接下架，除非你确定他们是恶意的。
4. 为什么 https://github.com/goldendict/goldendict/issues/1383 你把你的回复删掉了并且不回应？既然有那么多的证据，更应该帮助 goldendict 来将这些“无道德底线的商业公司”打垮不是么？

不会盲打的唯一原因：代码写的太少。

写的多了根本不可能不盲打，不需要刻意练习。就和你手机上微信的图标位置一样，你没有记过，但你永远知道它在哪。