2035 年，一个互联网公司，一名 10 后的的产品经理，在台上宣布着自己的产品规划，他想做一款产品，不论是什么操作系统，什么设备，什么软件，这个产品的内容都可以正确的显示。不需要下载什么 App 或者小程序，不需要特定的应用才能打开，到时候一定可以统一整个互联网。
这时候，台下有一名 90 后的老年员工举手：
你说的这个东西，是不是叫「网页」。

光猫应该是不支持 ipv6 ，国内 ipv6 纯减速，压根没必要开

看到一半我就猜 op 是不是字节的。
点开博客，果然。

有无关键指标透露下，比如需求吞吐量和 go 转 rust 的研发消耗情况如何？

作为一个被 nexusphp 折腾过整个学生时期的告诉你。。
这玩意 ipv6 的支持稀烂（

@jlak
老实说，写 go 也五六年了，除了业务代码 AI 有点用以外，大多数情况我体感是 AI 只能帮倒忙。
尤其在写一些很底层的部分时，由于变量名称省略较多，经常都是 1-2 个字母的变量名，然后 AI 给你写的代码光给它 debug 就要费劲很多，还容易看错。

因为 go 最初设计就是，尽量抹平新手和老手之间的理解与认知 gap ，让一个团队里不同水平的工程师都可以互相合作。

简单点说就是下限和上限差别很大。这点在框架开发上其实蛮牢的，你要么接受设计者的哲学，要么就自己另起炉灶。
这可能也是 go 在社区口碑两极分化的原因，喜好的人很喜好，不喜欢的人就是不喜欢。

另外，你才刚碰到资源规格的问题。
如果你的资源池有好几代机器，具备不同的 cpu/内存/网络甚至磁盘速度。
你还得考虑基准核/node taint 之类的指标。

平台得定义一个基准性能指标，或者避免同一组工作负载分布在不同规格的节点上。

只要你不是无良云厂商，就
不要碰 overcommit ，不要碰 overcommit ，不要碰 overcommit
重要的事情说三遍。

正规做法是接入 VPA ，根据汇总的监控数据建议合适的 request/limit ，督促设置不合理的应用负责人调整资源配置。
通常来说 request 比 limit 小 0.01 就行了。

乱用 request/limit 后果就是你的成本预算和资源核算压根没法做。更不要说做保障了。
k8s 之所以有 request/limit 概念是因为它底层使用的 linux cgroup 有这套东西，所以单纯就搬了上来，实际上这个东西大多数人玩不好，而且 BestEffort 策略本质上是算是舍弃 QoS 的，这又和很多服务场景需求矛盾。

结论：别给你的 user 灌输这堆垃圾概念，直接告诉他实用实报，可以随时通过 VPA 调整就完事了。

声明式+agent ，自研吧。做好任务管理下发，执行和回报交给 agent 。
超大规模的想走 worker+shell 真的是坐大牢。

当然，我觉得最简单的方式。k8s ，damonset 跑 agent ，或者直接上 job ，日志也能统一回收。以 pod 状态/job 状态作为任务执行的结果标识。

学历专业不对口的情况下，想跳槽确实有点难。
小公司嘛，要么做屎山的 king ，要么就骑驴找马。

你有没有考虑过，停水的时候，你家水塔如果常开反倒会给隔壁供水

这编译器优化都是老黄历了
unsafe.String

@atom42 你点之前看菜单名称了吗，还是说按记忆点的位置没看是什么

web 还是客户端？稍后再看我也用但是没碰到你说的问题