V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Nugine0  ›  全部回复第 4 页 / 共 6 页
回复总数  120
1  2  3  4  5  6  
@FrankHB 我认为根据特定场景去全面肯定或否定某种技术方案也是不妥的。“大多数”和“正确性”并没有必然联系,事实上很多工程决策后来都变成了历史遗留问题。
既然你这么推崇异常,评价一下另一种异常方案 herbception ?
@FrankHB 你说的“注定不可能克服”的“问题”当然是存在的,但在某些场景中就不算问题,不然谷歌为什么禁用 C++异常呢?
从其他错误处理方案的视角看,异常也存在注定不可能克服的问题,比如开销大、不能跨语言兼容、不适合嵌入式系统等。
总之就是一句话,没有银弹。
@FrankHB
首先改变 API 行为本身就是有风险的,下游不用改源码不代表没有行为会被破坏。你说的“工程劣势”在我看来不算什么问题。
其次异常的实现方式不止 unwind 一种,也不一定能保证二进制兼容。而且 unwind 在非 happy path 的开销非常大,不一定值得冒着性能退化的风险去优化 happy path 。
我只能说异常也不是银弹,用什么错误处理方式要根据具体场景决定。
一般有三种可能
1. 查询用户成功,取得有效值
2. 查询用户成功,但用户不存在
3. 查询用户失败

第 2 类是否算作错误,要根据业务决定。
通常情况下在出错时不可使用返回值,所以选 1 更好。
@FrankHB 所谓的 error neutrality 就是指默认向上传播错误?那 Rust 的问号运算符在这些语言中应该是最简单的,毕竟只要打一个字符。
2022-08-02 16:00:44 +08:00
回复了 ecloud 创建的主题 Rust 感慨一下, rust 的性能竟然这么好
@novolunt 然而用 zig 写的 bun 正苦于修 segfault
2022-08-02 15:59:51 +08:00
回复了 ecloud 创建的主题 Rust 感慨一下, rust 的性能竟然这么好
@changnet 强转时不考虑对齐吗?小心哪天爆炸……
2022-07-06 19:48:30 +08:00
回复了 Exuanbo 创建的主题 JavaScript Bun 发布了 beta 版本: Bun is a fast all-in-one JavaScript runtime
作者单人输出能力很强,测试效果很好,值得关注。
不过 bun 还处于早期,issue 里一大堆段错误,也有内存泄露和崩溃问题,有点担心它的性能是不是通过牺牲安全性和正确性换来的。
2022-06-13 12:18:33 +08:00
回复了 thewiredguy 创建的主题 Go 编程语言 我怎么觉得 Java 的 JNI 比 Go 的 CGO 要好呢?
@icexin Rust/C++/Zig 都可以无缝调用 C 语言,都有无栈协程,手动(半自动?)管理内存,允许声明与 C 一致的内存布局。相比 C++,Rust/Zig 的包管理和交叉编译更方便。你说的这些问题在系统级编程语言中都有完善的解决方案。
2021-04-28 11:38:52 +08:00
回复了 rv54ntjwfm3ug8 创建的主题 Rust 想用 Rust 写一个高并发论坛,什么框架合适?
高并发不是换个语言或者框架就行的。
web server 速度再快,全卡在数据库上,那又有什么意义。
目前 rust web 框架还做不到像其他语言那样友好,速度快一两个数量级其实不算什么优势。
2021-04-28 11:32:32 +08:00
回复了 syaka 创建的主题 Rust rust 的模块化太繁琐
你可以在一个文件内写多个模块,也可以用 include! 把多个文件合成一个模块,还可以用 #[path="xxx.rs"] 把模块指向不同名的文件。

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

不喜欢默认模块配置的话,有很多比较方便的方法修改行为。
2021-03-19 18:48:18 +08:00
回复了 nickyang897897 创建的主题 Rust Rust 它凭啥这么难?学习路线这么陡峭。。。。
@fengjianxinghun 那个是低层封装,实际要用还得再封一个高层的 proactor 出来。
io_uring 也提供了多种用户空间 API 的可能,完全可以拿 rust 重写 c 库,换一条路去尝试。
2021-03-19 14:40:50 +08:00
回复了 nickyang897897 创建的主题 Rust Rust 它凭啥这么难?学习路线这么陡峭。。。。
@wellsc 目前只有最简单的功能,但塞了不少优化。
一般情况下,进行一次 IO 无需任何额外的堆分配。未来用上 io_uring 的最新特性后,可以做到进行一次 IO 连系统调用也不需要。
有线程、协程、原子指令、互斥锁、信号量、对象池、状态机、小对象优化、自定义虚函数表等知识点,unsafe 自然也没少用。

https://github.com/datenlord/datenlord/pull/193
2021-03-19 13:48:37 +08:00
回复了 nickyang897897 创建的主题 Rust Rust 它凭啥这么难?学习路线这么陡峭。。。。
最近完成了一个基于 io_uring 的 proactor,几百行一次过,刚写完就能跑起来
合并排序数组不是基础算法吗?应该有现成的轮子。
如果没有轮子,函数上面注释写清楚,加几个测试,没人会关心里面代码可不可读。
2020-10-05 21:44:14 +08:00
回复了 kidlj 创建的主题 Go 编程语言 要学 Go 的赶紧上车
@reus
把 if err != nil 换成 check(err),还是填一发打一枪。写个函数就不是“判断错误”了?真搞笑。

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

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

我说 go 的现有机制不行,需要新语法解决。你不肯接受,我还能咋办,难道顺着网线去 git push -f ?
我不会再浪费时间了,到此为止。
2020-10-05 17:35:19 +08:00
回复了 kidlj 创建的主题 Go 编程语言 要学 Go 的赶紧上车
@reus 看来你还没懂为什么现有机制不好用,不够用,不合适用。

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

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

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

以前还有 go 不需要泛型的说法,现在呢?
2020-10-05 12:06:47 +08:00
回复了 kidlj 创建的主题 Go 编程语言 要学 Go 的赶紧上车
@reus

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

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

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

我看是没有必要再回了,继续下去没有任何意义。
2020-10-05 10:34:42 +08:00
回复了 kidlj 创建的主题 Go 编程语言 要学 Go 的赶紧上车
@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 连标准库的人也不想写。

能用不代表它就是好的。
1  2  3  4  5  6  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1857 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 16:20 · PVG 00:20 · LAX 08:20 · JFK 11:20
Developed with CodeLauncher
♥ Do have faith in what you're doing.