文章《Placing Arguments》
作者：Yoshua Wuyts（Rust 团队成员）
文章《Placing Arguments》探讨了 Rust 中“placing arguments”这一设计理念的潜在实现方案及其面临的挑战。作者指出，尽管“placing functions”（即通过 #[placing] 标记的函数，允许在调用者的栈帧中构造值，避免复制并保证地址稳定）看似可行，但“placing arguments”（即在函数参数中直接接收一个“placing”的值，避免额外复制）却因执行顺序和借用检查等问题而难以直接实现。
作者通过示例说明，若允许直接传递表达式作为 placing 参数，会违背 Rust 现有的执行顺序语义，导致意外的 return 或 panic 行为，甚至引发借用检查冲突。为解决这些问题，作者提出采用闭包（closure）作为折中方案，即让函数接收一个返回待构造值的闭包。例如，将 Vec::push 改为类似 Vec::push_with 的方法，接收 impl #[placing] FnOnce() -> T 类型的闭包，从而显式延迟值的构造时机，避免执行顺序和借用问题。
然而，这种方案会导致新旧 API 并存，旧 API（如 Vec::push）逐渐被新 API（如 Vec::push_with）取代。作者进一步提出“edition-dependent path resolution”的设想，即通过 Rust 的 edition 机制，在不同版本中透明地重命名或替换 API，使新 API 能以旧名称提供，从而平滑过渡，避免用户困惑。
总结：placing arguments 因兼容性问题无法直接实现，需通过闭包和 edition 机制逐步引入，以兼顾效率与向后兼容性。
阅读：https://blog.yoshuawuyts.com/placing-arguments/
Reddit：https://www.reddit.com/r/rust/comments/1mq6w1s/placing_arguments/
Agentgateway：快速、功能丰富的 Kubernetes 原生代理
Agentgateway 是一个用 Rust 编写的新的开源代理，它由一支长期使用 Envoy/Istio 的团队构建的，我们发现它无法满足 AI 对网络基础设施日益增长的需求，例如支持 LLM 协议（基于令牌的速率限制和监控、提示护栏、模型故障转移等）、MCP、A2A 等。
虽然它最初的动机是基于人工智能的，但它现在已经发展成为一个成熟的通用代理。在这个（非常拥挤的！）领域，它的主要差异化因素之一是其原生的 Kubernetes 支持。在 40 个 Kubernetes 网关 API 实现中，agentgateway 是唯一用 Rust 编写的（Linkerd 支持该 API，但仅限于服务网格，而不是网关）！此外，它是唯一专为 Kubernetes 设计的代理。这种专业化带来了显著的性能提升——在路由规模测试中，agentgateway 仅使用一小部分资源即可处理相同的负载：
从技术角度来看，agentgateway 建立在 Rust 的标准框架之上——Tokio、Hyper、Tonic 等； cel-rust 也是其中的重要组成部分 。以下是一些可能存在争议的决定：
-
我们没有使用 Tower（或任何其他类似的中间件设计）。虽然这些中间件对于获取现成的可复用层非常有用，但我觉得自己实现层过于复杂。例如，比较一下 Tower 和 Agentgateway 中将标头设置为敏感的简单服务（当然，Tower 的功能略多一些）。
-
我们没有使用 Pingora ，虽然它现在在 Rust 的新代理中似乎很常见。Pingora 提供的功能集与我们想要的功能没有太多重叠，而且我们希望完全拥有自己的堆栈，而不是被一个（有点）固执己见的库所束缚。此外，选择 Pingora 意味着放弃 Hyper，考虑到我们过去使用 Hyper 的经验，这并不是我们想要的。
仓库：https://github.com/agentgateway/agentgateway
Reddit：https://www.reddit.com/r/rust/comments/1mq4gvm/agentgateway_a_fast_feature_rich_kubernetes/
Cel-cxx：适用于 Google CEL 的现代、类型安全的 Rust 库
一种用于通用表达语言 (CEL) 的类型安全 Rust 库，建立在 cel-cpp 之上，通过 cxx 实现零成本 FFI 绑定。
核心设计原则：
- 类型安全 ：CEL 表达式和函数签名的编译时验证
- 零成本抽象 ：以最小的开销直接将 FFI 调用到 CEL-CPP
- 内存安全 ：Rust 所有权系统可防止常见的集成错误
- 符合人体工程学的 API ：构建器模式和自动类型推断减少了样板
- 可扩展性 ：支持自定义类型和异步操作
该库提供了一个连接 Rust 和 CEL-CPP 的分层架构：
- 应用层 ：用于环境构建和表达式评估的高级 API
- 类型系统层 ：Rust 和 CEL 类型之间的自动转换
- FFI 层 ：通过 cxx crate 实现与 CEL-CPP 的零成本绑定
- CEL-CPP 层 ：Google 的解析和评估参考实现
仓库：https://github.com/xjasonli/cel-cxx
Reddit：https://www.reddit.com/r/rust/comments/1mptg6z/announcing_celcxx_020_a_modern_typesafe_rust/
讨论：真希望 Rust 有可变泛型和命名参数，用于 UI 开发
感觉命名参数 RFC 并没有得到太多关注，而可变参数也停滞不前。在尝试了不同的 UI Kit 以及 Composer 和 Builder 风格的 API 之后，我意识到可变参数 + 命名参数可以大大减少宏 DSL 的使用——Dart 在这方面做得非常好。但考虑到目前人们的注意力都集中在分配器和异步 trait 上，我怀疑这些功能短期内很难见到。：（
高赞回复：
“对于命名函数参数 - 看看 bon 这个库。想要更轻量级的方法（就编译时间而言），可以尝试将函数转换为一个结构体，该结构体接受所有相同的参数，但需要命名。然后在结构体上添加一个类似 .call() 的方法。我一直在使用这种方法，效果很好”
Reddit：https://www.reddit.com/r/rust/comments/1mprqw6/really_wish_rust_had_variadic_generics_and_named/
--
From 日报小组 苦瓜小仔
社区学习交流平台订阅：
评论区
写评论还没有评论