1. subcommand
2. 接受 unsafe 的话可以考虑 leak 之后把指针放全局变量？不过感觉全局变量应当少用，最好是参数传递形式。

除了工资高和工作闲以外我也+1

学了点 Rust
明年也要开心 coding 。

所有现在 work 的方法都可以做成生成器拿去喂网络，基本无解的。
从另一种角度理解，前面的图像处理的 trick 算是加密算法本身，而根据密码学的常识，不能试图通过保密算法本身是行不通的。
可以和朋友约定一个 pre-shared key （比如搞两张图，叠起来看才是最终图像，其中一张就是 key ），或者每次协商一下==

@whimsySun 场景是合适，我们内部也决定做，但是还没做出来🤣 (tg 同名

@whimsySun 这个确实是我们的目标场景（我们组主要做 ServiceMesh ）。Edge Proxy 和 Mesh Proxy 都是比较理想的应用场景。

@nameyukan

谢谢批评，目前文档确实欠缺。当前也并不是生产 ready 的，我们明确说了项目仍处于非常早期的阶段，相信你从 0.0.x 的版本号上也能看出来。
但我觉得，开源并不是一定要先做到完美。众人拾柴火焰高，我们希望能够和志同道合的人、有同样需求的人一起来把它变完美。作为一个不涉及公司业务细节的通用组件，开源开发并不会带来任何不便；反而在大家的监督和 review 下 commit 质量会更好。

@Kilerd 是的，我们开源的本意也是为了一起建设这类基于完成通知 IO 的生态。这个 rt 只面向限定场景，并且至少我们内部确实需要用，所以后续也会持续投入。

@Mistwave

并不广泛，在业务侧用户很少。我们认为，一来是因为业务不那么 care 性能，而 rust 上手成本又很高，二来是因为想用也用不了，因为 rpc 等组件没有。我们前阵子在做这堆组件(我之前有帖子分享做 rpc 框架)，给想用却没法用的业务用的机会。现在业务基本能用 rust 写了，不过使用者仍不算多。

但是我们认为在基础架构内部 rust 的未来还是很美好的。内核组已经有一些应用了，我们 Mesh 这边也计划造下一代基于 rust 的数据面代理，公司内的 rust 群也有接近 2000 人。

@kerro1990

你不用不代表没人用哦。

@Kilerd 没有拷贝，我们这部分设计（以及部分代码）其实是直接从 tokio-uring 里搬的，不过我们基于 GAT 把这部分抽成了 trait 。
带所有权的接口设计就是用户扔所有权进来，io 完成时再扔回去。这样可以保证在 sq 推进去之后 sq 中的 buffer 指针一直是有效的。

@ScepterZ 因为连接数是固定的，所以在达不到设定的 QPS limit （限制做在客户端）时，在服务端的感知是完全一样的。

@nameyukan 感谢批评，测试这块后续逐渐会逐渐补齐。目前 unsafe 不太多，通过 Rust 本身基本可以保证没有内存问题。逻辑问题确实需要，这块目前在快速推进还不完善。

@araaaa windows 暂时不会支持，后续可能会通过引入 mio 来支持 mac 和无 iouring 的 linux 。

@tulongtou 目前公司内部计划基于这套 Runtime 做下一代高性能 MeshProxy ，但尚无生产实际使用。开源出来也是希望能够和大家一起建设生态：）

@Kilerd 是的，我们的场景上和 Tokio 是不同的。
可以看和 tokio 单线程的对比数据（这时其实主要差别就在于 epoll 和 io-uring 了）。
buffer 我们采用的 Tokio-uring 的做法，直接拿所有权，用完还回去。

@Mithril 用 Rust 上线更安心～

@fyooo 谢谢支持，也欢迎大家参与！

spotify

人家水平不如你，但是人家工资比你高啊[手动狗头]

@sungnix （更新了，不过 CDN 有较大延迟）微信群基本没动静，建议飞书 :)

@necomancer 安装 conda 本身也要手动区分平台并下载安装包（并且也不小），感觉也有点麻烦。