@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 不同。

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

@reus 用 panic/recover 来处理 error 就是一种混淆的做法，不然为什么不设计成 try/catch ？

当然，你完全可以不理会我的看法，毕竟我“水平不高”。

@reus

你对我那句话的理解，明显有严重偏差。

“错”是指编译不过，“真正”的写法是指能编译通过的写法。非得说成这样才明白？

你说过什么，想表达什么意思，清清楚楚。

你说 panic 是代码本身的问题。

但 error 显然是运行时的问题，二者不能混为一谈。这不是我一个人的看法，网上文章多了去了。

能用 panic/recover，不代表 if err != nil 就是好的。别人说事物 A 不好，你说可以用事物 B，并反过来指责别人，真是荒谬。

我倒是很佩服能莫名其妙发火的人，别误会，说的不是你。

@reus 火气这么大，不如去写点代码冷静一下，然后再来教别人怎么错误处理。

@reus 绝了，我说“编译不过就是错”，没说必须要用两个分支，真能脑补。
我也没说 rust 更优雅，我说的是 go io.Reader 是没有 union type 造成的设计失误。

@reus 写函数替代 if err != nil 不能改变控制流，用 panic/recover 又与你之前的言论矛盾，我很好奇你是怎么写的。

“就算返回的是指针，且函数有问题，那后面如果遇到解指针，那就会直接 panic，表明程序需要改，是不需要写代码做检查的。”

@reus
编译不过就是错，不知道你口中的“错”还能是什么？
你认为我有偏见，你这说法本身就是偏见。搁这套娃呢，火气真大。

我讲了设计失误，你上来就是“双标”，谁有偏见？

@reus 再换成 C，没人会说 C 难吧。
看看 C 有什么，基于错误码的错误处理，预处理器。
C 也要挨个判断返回值，但人家有宏。
go 稍微给点语法糖都不会被喷 if err != nil，但还是坚持，估计以后也会一直被喷。

Linux 内核是用 C 写的，是个人都能轻松学会 C，能读 C 代码不代表能懂。
go 所谓的简单，真的能让人“懂”大型项目？光阅读有什么用？我看未必，把代码复杂度和语法复杂度混淆起来而已。

go module 就凭空增加了一项学习成本，将要出来的泛型也是。

减掉的复杂度最终都会加回来，成为内卷的工具，等着瞧。