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

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

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

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

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

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

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

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

@reus
前面人给的 rust 代码是错的，你却拿这个举例，算不算被钓鱼？
我在谈事实，你却直接攻击别人“双标”。看来这就是某些人的素质，真是“高”啊。

1. rust 的真正写法是 read(&mut buf)?，或者用两个分支的 match 分别处理成功和失败。成功分支中有可能是已读完的情况。
go 的 if 是 fall though 的，需要理解的代码范围更多。
你以为我要说 rust 更优雅？错了。
我要说的一直是：go 自称简单，但实际上并不简单。
一个自称简单的语言和一个公认难学的语言比心智负担，说出来丢不丢人？

2. 我定义的正常函数就是要么成功要么失败，语义不同就是增加负担，对人不友好就是反人类，还要怎么解释？
io 本来就有固有的复杂度，却在这里节省一次调用，简直莫名其妙。
我要不要再去研究一下“节省”和“不节省”的等价性？我认为这就是设计失误。你开心就好。

3. rust 的 lint 的确是语言机制的一部分，具体表现为 rustc 内置 lint 和 clippy 扩展 lint 。我还说 doc 和 tests 也是 rust 语言机制的一部分，请问有没有意见？

再强调一下我的论点：go 自称简单，但实际上并不简单。

能看成捧一踩一的，你开心就好。

@reus 再说 rust 。
non_exhaustive 归 lint 管，上游新增了字段会被 lint 查出来，可以自动化。
<https://rust-lang.github.io/rust-clippy/master/index.html#wildcard_enum_match_arm>
讲真的，不会有编程语言连这种程度的 lint 都做不到吧。

有异步运行时能把同步 IO 转异步 IO，依赖的就是非阻塞和 WouldBlock 。
Rust 异步运行时依靠社区，没 go 那么统一，某种程度上是弱点，但也给出了自由空间。

@reus 根据你的介绍，这个 io.Reader 显然是没有 union type 带来的设计失误。

按正常人的思维，调用一个接口要么成功，要么失败，应该用 union type 。但 (42, io.EOF) 算什么？叠加态？

你可以列很多理由说明这个设计合理，但改变不了它反人类的事实，它的语义和正常函数是不同的。这就是额外的心智负担，说好的大道至简呢？

go 阅读起来也不是那么容易。检查完 err 不检查空指针，直接挂了。调用栈追下去，一个 interface{}拍脸上，得，全动态了。

go 用看似简单的语法给人快速入门的错觉，真以为什么人都能看懂大项目？真以为换条赛道就能马上超车？路上的坑一个也逃不了，全要挨个踩过去。

Rust 才应该是真正的云原生语言，没开玩笑。
正反论据都很多，就不列举了。

在城市里，你接触的一切都是工业文明的成果。水电，网络，卫生，交通，衣服，食物，等等，都是工业化社会才能提供的基础服务。

回到刀耕火种的时代，光是生存就要竭尽全力，哪有时间想这些。

只有在生产力爆表的未来，才可能实现理想中的田园生活。

@dafsic 这和编程语言有什么关系？

@dafsic ¿

rust 用问号运算符和异常差不多爽，要严格处理错误可以当场判断，能确保错误被处理，上下都涵盖了。
C 还能用宏，go 怎么偷懒？没法偷懒不就是反人类吗？

所有语言的异步 IO 都需要操作系统的非阻塞支持，比如 epoll 。
应用注册 IO，当 IO 完成后，系统会通知应用处理对应事件，这样一个线程就能同时进行多个 IO 操作，不用被阻塞调用卡住。

拿 js 举例，无栈异步语法分为回调、Promise 、async/await 三种，第一种是回调地狱，第二种链式调用开火车，第三种用同步格式写异步，最人性化。

再拿 go 举例，有栈异步语法与同步一致，调度器会在进行 IO 时自动把协程切走。py 在没有 async 语法时用的是 gevent 有栈协程，把同步操作自动换成异步，无需修改代码。

js 本身就是事件循环，无栈协程是加糖解决回调地狱。

py 有两种协程，gevent 的有栈协程，asyncio 的无栈协程，都是为了提高 IO 效率。

go 是有栈协程，m:n 调度，多个线程上可以运行多个协程，卡住时其他线程还会偷走多余的任务。本来一个线程只能进行一个 IO 操作，现在可以同时进行多个，提高 IO 效率。

c++20 的是无栈协程，但可能有隐式分配。

Rust 的是无栈协程，没有隐式分配，调度器要自己选择第三方库，基本上都有工作窃取算法。其中的无栈协程可以不用分配直接放栈上执行，也可以交给调度器作为顶层 future 执行。而且 Rust 没有 GC，实时性可以有保证。

个人认为，在各种语言中，Rust 的无栈协程是最轻量的。

两年前开始学 rust，现在风向要变成 rust 了。
等 2022 再猜下一个风向技术。

说明 V2EX 引流效果显著，应该多展示

deno 承担包管理，提供标准库，提供一系列工具，拥抱 web 标准，部分模块与浏览器直接兼容，这都是大一统的思想。对于个人来说，它不会限制开发的灵活性，而是减轻了在各种配置中折腾的痛苦。

安全性限制发展？如果向用户要权限会限制发展，那这个实现一定是有问题的，正常权限不会引起反感。

吃饭看现在，追新看未来，deno + rust 的组合前景美好，值得投资。

npm 兼容层有人在做，只要有轻松迁移的方案和第一个杀手级框架，相信会出现大规模迁移到 deno 的浪潮，这需要时间。

后端方面，ts 从语言设计、开发效率和表达力等方面讲都是一流的，用 ts 写后端是一个值得尝试的选项，deno 还缺成熟的后端框架。

DENO_DIR 是可以指定的，不一定是全局，这就提供了 vendor 和项目隔离。

deno 有锁文件，能查出模块是否被篡改，不需要手动验证。

去中心化的包管理也能中心化，想想，如果 npm 下场提供 deno 模块托管会怎么样，这就能解决生态问题。

默认 ts 是一个巨大优势，没错，是巨大优势。
ts 是 js 超集，它的类型系统就是最大的卖点，不能接受动态火葬场的人无论如何也不会回去写 js，反过来转移却很轻松。向 ts 的单向转移趋势已经非常明显了。

同 y9000x 。
先调硬盘模式才能装双系统。
装 ubuntu 不能外放，只能用耳机。
从 windows 重启到 ubuntu 就不能用耳机口，必须关机启动。
windows 使用正常，ubuntu 缺声音。
性能确实挺香的，但有以上缺陷，对产品目标群体很不友好。