Differential：一种像本地函数一样的类型安全 RPC

幂等性与交付语义

• 线程的大部分内容都在讨论“幂等性”功能。
• 批评者认为，该框架无法让任意带副作用的函数真正幂等；它最多只能提供至多一次或至少一次语义，而不是恰好一次。
• 据称该系统使用幂等键加锁/租约；对于标记为幂等的函数，它通过只向某个 worker 发起一次调用，力求实现至多一次。如果没有标记，失败的调用可能会在另一台机器上重试（至少一次）。
• 一些评论者说，文档和营销在这些区别上表述模糊，可能会误导用户，尤其是在示例涉及支付时。
• 有人建议把这个功能重命名为类似“tryOnce”或“retry policy”，而不是“幂等性”。

错误处理、重试与 AI

• 错误在异步函数中以异常形式暴露；丢失回复导致的超时也会以类似方式处理。
• 有一个基于 AI 的“预测性重试”功能，会将错误（例如连接重置、死锁）分类为暂时性错误并自动重试。
• 这是可选启用的，目前是全局（按集群）开关；有人认为它应该按函数配置，并质疑在这里使用 AI 相比显式注解的价值。
• 担忧是：如果 AI 把一个非幂等操作误判为可重试，副作用可能会被应用两次。

RPC 抽象与分布式系统问题

• 许多人对“像本地函数一样”的宣传语提出反对，警告说掩盖网络现实（延迟、部分失败、分区）在历史上会导致脆弱的分布式单体。
• 也有人认为，只要开发者始终清楚自己处于“分布式系统的世界”里，RPC 式的易用性并没有问题。
• 更广泛的争论在于，让远程调用看起来很容易，究竟是在鼓励糟糕的架构，还是在赋能那些已经选择了微服务的团队。

架构、范围与序列化

• 该产品被描述为面向后端/微服务的类型安全 RPC，由一个集中式控制平面协调调用、重试和健康检查（通过集群化保证可用性）。
• 有人将其视为“trpc/rspc + service mesh”；也有人称它为“带花哨功能的 service mesh”。
• 它以 TypeScript 为先，这让多语言环境与基于 IDL 的系统（如 gRPC）相比引发担忧。
• 参数目前必须可 JSON 序列化；函数/promises 还不支持。批评者说，这回避了构建真正分布式语言运行时的更难部分（闭包、别名、可变性语义）。

反馈与成熟度

• 一些评论者觉得这个想法很有意思，并指出大型公司内部也有类似系统。
• 许多人批评文档/营销不够清晰或有过度宣传，尤其是在幂等性和可靠性保证方面，但也承认该项目还很早，仍在迭代中。