V2EX › Nugine0 的所有回复 › 第 4 页 / 共 7 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7

❮

❯

2022-08-15 20:04:07 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@FrankHB 你这么长篇大论下来，虽然确实说了很多知识，但还是在不断回避我关注的问题……
建议把你的观点整理起来发篇技术文章，比这样在评论区打转更有效率。后面我不再回复了。

2022-08-15 02:42:11 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@FrankHB 你说开销是实现细节，对不对呢，当然对，但很多时候调用方确实有理由去关注一个 API 在不同 path 的性能表现。和类型与 Monad 能做到以多占一个寄存器的代价(先不管 go 这个用积类型的奇葩)，去消除错误路径的额外开销，这时异常(unwind)的开销就成了劣势。给和类型与 Monad 提供对应的语法糖，也能解决啰嗦的问题。
至于函数签名，有人认为一个函数会不会出错应当体现在签名中，有人认为应当透明，这在各自场景里都是对的，但不能说哪边就是绝对正确。硬要无视场景区别去推行所谓“大多数”的决策，我觉得只会收到一大堆黑人问号。

2022-08-15 00:37:32 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@FrankHB 我认为根据特定场景去全面肯定或否定某种技术方案也是不妥的。“大多数”和“正确性”并没有必然联系，事实上很多工程决策后来都变成了历史遗留问题。
既然你这么推崇异常，评价一下另一种异常方案 herbception ？

2022-08-14 11:42:58 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@FrankHB 你说的“注定不可能克服”的“问题”当然是存在的，但在某些场景中就不算问题，不然谷歌为什么禁用 C++异常呢？
从其他错误处理方案的视角看，异常也存在注定不可能克服的问题，比如开销大、不能跨语言兼容、不适合嵌入式系统等。
总之就是一句话，没有银弹。

2022-08-13 21:13:35 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@FrankHB
首先改变 API 行为本身就是有风险的，下游不用改源码不代表没有行为会被破坏。你说的“工程劣势”在我看来不算什么问题。
其次异常的实现方式不止 unwind 一种，也不一定能保证二进制兼容。而且 unwind 在非 happy path 的开销非常大，不一定值得冒着性能退化的风险去优化 happy path 。
我只能说异常也不是银弹，用什么错误处理方式要根据具体场景决定。

2022-08-13 15:10:32 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

一般有三种可能
1. 查询用户成功，取得有效值
2. 查询用户成功，但用户不存在
3. 查询用户失败

第 2 类是否算作错误，要根据业务决定。
通常情况下在出错时不可使用返回值，所以选 1 更好。

2022-08-13 15:02:22 +08:00

回复了 ryalu 创建的主题 › Go 编程语言 › 关于 Go 在 `Return Nil or Pointer to Empty Struct on Error` 上的讨论？

@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-22 09:07:18 +08:00

回复了 YadongZhang 创建的主题 › 职场话题 › 实际开发过程中，会因为 lgn 倍的时间复杂度优化而牺牲代码可读性吗

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

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 不需要泛型的说法，现在呢？

1 2 3 4 5 6 7

❮

❯