@franklu 不是说语法没问题，而是语义，或者是整体的设计，还没有完善就急着稳定化，以至于后面发现问题又不能 breaking ，就只能屎上雕花了。
最典型的就是 async trait ，还没设计好之前，就不该把 async 稳定化。

@sakujo 他确实是看上微信了，但开放的互联网应该很难做出来第二个微信这种毒瘤。

@glfpes 确实，看到拿火影隐喻的，总有一种在美化他们的感觉。

@catalysia 上面都是在骂平台进行内容审查的，你这里反而抱怨的是平台没有进行足够的内容审查。
每个人是自己的第一责任人，不要当巨婴。

@kljsandjb aysnc rust 太着急了，还没有设计好就急不可耐的稳定化，后面的库/语言改变只能不得不继续屎上雕花，这样下去迟早 rust 会成为第二个 cpp 一样的缝合怪。

@des 这不是 clone 的问题，在你不使用非常高级、复杂，generic 参数特别多的类型时（ async 和基于 async 的框架就是在使用，并且抽象泄漏严重，使用它们你不得不关注内部细节），rust 一点都不困难，仅用 ide 的编译器错误提示可以减少大量其他语言开发时不断编译运行的试错次数。
至于不想处理静态的引用生命周期，替代方法是用 Rc/Arc + clone 顶着，通常你想要一个非静态生命周期的引用不代表你想用 clone 。

岗位真的是不断减少吗，审核岗不是越招越多。

rust 写起来非常爽，在你碰到 async 之前。

@mingmeng 开放服务被严重限制，公网 ipv4 其实没什么用，尤其在目前 cgnat 普遍 full cone ，甚至部分地区支持 PCP 开放端口的情况下。且 ipv6 基本用户侧已经全面支持，远程访问基本没有障碍。
公网 ipv4 更容易被广告公司追踪，也就只有 PT/PCDN 等滥用宽带的用途了，所以高上行和公网不同时给是非常合理的限制。

wds 中继标准混乱，一般需要和主无线 AP 同厂商的设备才能正常达成 WiFi 桥接，当然即使不兼容一般也能回退到 nat 转发的方式。

第一种办法需要你的客户端设备支持，至于第二种就很简单了，Linux 下直接写个 udev rule ，插入 usb 设备自动执行对应脚本，挂载并调用 rsync 增量同步，可以让 gpt 帮你写。Windows 的话好像也有一些类似 U 盘小偷的软件，能后台自动复制插入的 usb 设备的文件。

再有帖子讨论为什么不生育、丁克之类的时候，这个帖子是一个完美的案例。

@gynantim 他们不是不知道黄推是杀猪盘，他们只是或明示或暗示在不被某实体监管的地方谈论不被某实体允许的内容的人是傻逼。

效果差就本地运行意义不大？本地运行最大的意义是可以自由使用，使用量、隐私数据、绕过法律道德伦理审查。

@body007 看了那个帖子，有人发通过 udp 转发使用 HTTP3 效果不如 UDP over TCP ，可能是 mtu 不对，TCP 会自动协商 mtu 所以错了也没什么影响，但 udp 就依赖上层协议了。
之前买了个 ss 协议支持真 udp 转发的机场，用来转发自己的 wireguard 隧道，发现性能很差，居然比 UDP over TCP 慢很多。一开始以为是 qos ，但后来抓包发现有很多 ip fragmentation ，调整 mtu 后瞬间就好了，配合 quic 0-rtt 打开网站响应极致丝滑。
至于 UDP over TCP 的意义，其实就两点，一是连通性，部分公共网络会阻断所有 UDP 流量，也有不少只支持 TCP 的代理提供商，尤其是被攻击的时候关掉 UDP 。第二点就是在无法使用 fake tcp 等需要完整 3 层的情况下缓解运营商 qos ，但 tcp 究竟比 udp 优先级高多少也不好说，较差的网络环境下可能通过前向纠错的隧道表现会更好。

@pengtdyd CPU 模拟还是很常见的，毕竟量子计算机目前还是实验室里的东西，基本没有实际应用，感兴趣可以玩一下微软的 Q#，运行逻辑和现有计算机差异非常大。
至于“自主可控”就没什么好说的了，有这个头衔的东西要么是骗经费的，要么终有一天会剥夺你使用非“自主可控”的同类的权利。

udp over tcp 这个问题无解，tcp 就没法控制丢了的包不重传，上层应用根本都没法知道有包丢掉了。
为了解决 qos ，一般都是伪造成 tcp/icmp ，但这样也就没法通过 tcp tunnel 。
quic 彻底普及取代 tcp 后就没有这些问题了，不但解决 udp 地位低下的问题，且 quic 不像 tcp ，它是可以构建不可靠信道的。

@sanshao124 自建的服务 SQLite 最合适，一个服务跑一个 pg 开销太大了，而且版本迁移/备份都比较麻烦。