@FrankHB 所谓的 error neutrality 就是指默认向上传播错误？那 Rust 的问号运算符在这些语言中应该是最简单的，毕竟只要打一个字符。

@novolunt 然而用 zig 写的 bun 正苦于修 segfault

@changnet 强转时不考虑对齐吗？小心哪天爆炸……

作者单人输出能力很强，测试效果很好，值得关注。
不过 bun 还处于早期，issue 里一大堆段错误，也有内存泄露和崩溃问题，有点担心它的性能是不是通过牺牲安全性和正确性换来的。

@icexin Rust/C++/Zig 都可以无缝调用 C 语言，都有无栈协程，手动(半自动?)管理内存，允许声明与 C 一致的内存布局。相比 C++，Rust/Zig 的包管理和交叉编译更方便。你说的这些问题在系统级编程语言中都有完善的解决方案。

高并发不是换个语言或者框架就行的。
web server 速度再快，全卡在数据库上，那又有什么意义。
目前 rust web 框架还做不到像其他语言那样友好，速度快一两个数量级其实不算什么优势。

你可以在一个文件内写多个模块，也可以用 include! 把多个文件合成一个模块，还可以用 #[path="xxx.rs"] 把模块指向不同名的文件。

在 lib.rs 里还能一次性写完整个项目的模块树，完全不需要额外的 mod.rs

不喜欢默认模块配置的话，有很多比较方便的方法修改行为。

@fengjianxinghun 那个是低层封装，实际要用还得再封一个高层的 proactor 出来。
io_uring 也提供了多种用户空间 API 的可能，完全可以拿 rust 重写 c 库，换一条路去尝试。

@wellsc 目前只有最简单的功能，但塞了不少优化。
一般情况下，进行一次 IO 无需任何额外的堆分配。未来用上 io_uring 的最新特性后，可以做到进行一次 IO 连系统调用也不需要。
有线程、协程、原子指令、互斥锁、信号量、对象池、状态机、小对象优化、自定义虚函数表等知识点，unsafe 自然也没少用。

https://github.com/datenlord/datenlord/pull/193

最近完成了一个基于 io_uring 的 proactor，几百行一次过，刚写完就能跑起来

合并排序数组不是基础算法吗？应该有现成的轮子。
如果没有轮子，函数上面注释写清楚，加几个测试，没人会关心里面代码可不可读。

@reus
把 if err != nil 换成 check(err)，还是填一发打一枪。写个函数就不是“判断错误”了？真搞笑。

你敢把 panic 作为普通错误，作为接口的一部分，抛给库的使用者吗？如果不敢，就说明 panic/recover 不是错误处理的正解，如果敢，那祝你好运，别被 issue 挂起来。

如果未来喷 if err != nil 的不见了，那真是一件好事，这说明 go 终于拿出了好用的错误处理方案。

我说 go 的现有机制不行，需要新语法解决。你不肯接受，我还能咋办，难道顺着网线去 git push -f ？
我不会再浪费时间了，到此为止。

@reus 看来你还没懂为什么现有机制不好用，不够用，不合适用。

if err != nil 的处理通常是提前返回，处理起来非常重复繁琐。但函数不能改变控制流，panic 或类似 try 和 check 的新语法才能改。

panic/recover 是用来处理致命错误的，这是共识。拿它来代替普通错误处理是不合适的，这也是常见观点。跨越库的边界时，还得老老实实地判断错误。

真合适的话，官方为什么不设计成 try/catch ？真够用的话，那些官方参与的错误处理提案和讨论难道在放屁？

以前还有 go 不需要泛型的说法，现在呢？

@reus

四种或以上的情况难道不能归类为 成功 和 失败？别人贴的模式匹配是错的，难道不能指出来？写法是等价的，你看不出来，好意思说我？也奉劝你，不要再给我加戏。

语法糖不等于函数，明明是你在转移话题。

上网查查，panic 在编程语言中的语义就是恐慌，是致命的。我也明确说了，把 panic 当 exception 就是滥用？ Dave 确实不能代表设计意图，我也不能断定，难道你就能代表？懂的都懂，比你我更懂，行了吧？

我看是没有必要再回了，继续下去没有任何意义。

@reus

https://eli.thegreenplace.net/2018/on-the-uses-and-misuses-of-panics-in-go/

https://golang.org/doc/effective_go.html#recover

标准库为了简化错误处理去用 panic，违背设计意图，恰恰说明了 err 的繁琐，if err != nil 连标准库的人也不想写。

能用不代表它就是好的。

@reus
我看你是根本不懂 rust 。

read 的返回值是 Result<usize, io::Error>，不能用 ErrorKind 直接匹配，这是我说“错”的原因。

两分支是最原本的写法，用来论证“要么成功要么失败”，进一步论证 go 双元组的设计不好。

你说的四分支是等价版本，把直接跳转改成了 fall through，本质上是按情况处理 union type 的两个可能模式。

我说 14+29=42 不对，21+21=42 是对的。你偏要说 10+10+10+12=42 也是对的，反过来喷我，我也是服了。

变点写法就看不懂了？某一层封装一下，不就能用问号运算符了？这么简单的事实，还用我专门说？

标准库用问号运算符，把 Interrupt 暴露出去，一搜一大把，你难道也要说不对不对别人不是这么写的？

https://doc.rust-lang.org/src/std/io/buffered.rs.html#274

回到 go 上

https://dave.cheney.net/tag/panic

"When you panic in Go, you’re freaking out, it’s not someone elses problem, it’s game over man."

把 panic 当 exception 用，就是违反语言机制设计意图的，就是一种滥用。

再怎么 panic/recover，作者也不敢越过库的边界，无法代替 err 。

我说这是混淆的写法，有何问题？

@reus

有问题的程序，会直接 panic，而不需要写代码掩盖代码本身的问题。

用 panic / recover 处理错误，正是掩盖了代码本身的问题。

这不是双标，那什么是双标？

@reus 语法糖和函数一样？不然为什么有 check 语法的提案？

学到个教训，不说清楚就会引来死缠烂打。我原来的意思就是编译错误，因为 io Error 和 io ErrorKind 不同。

前提都是错的，那什么结论都有可能。你非要往其他方向理解，那你说的都对。