@reus It may return the (non-nil) error from the same call, 这个情况在底层是 posix IO 的情况下是不可能发生的,所以说 union type 完全可以表达正常的语义,不需要 int 和 err 同时出现.posix IO 是使用最广的 IO,因此 go 的 Reader 接口设计的有问题, 凭空出现了本应不存在的情况

另外 Rust 里标注#[non_exhaustive]的 enum 在 match 时没有`_`来匹配将来可能新增的字段是会编译错误的,因此不需要看到文档里写这句话也应该知道.用到了,编译不过,rustc 报错提示你 match 分支必须有_,自然就知道了.

如果你要读完那不应该用 read,应该用 read_to_end, 文档里写的很清楚,read_to_end 会忽略 ErrorKind::Interrupted.我不知道别人怎么写,但是我用写的命令行程序里 read_to_end 是直接用?抛到 main 然后直接输出错误退出程序的.磁盘 io 错误也没法处理,但是各种网络库里就要仔细处理了.

在 read 里暴露 ErrorKind::Interrupted 和 ErrorKind::WouldBlock 是因为异步运行时需要靠这个来进行异步 IO 操作.Rust 暴露很多细节是必要的,因为作为系统语言 Rust 允许程序员和最底层进行交互.go 搞有栈协程,因此这种 no blocking IO 的东西看起来很没有用.但是 go 程序员可不能在不改造编译器的情况下修改 go 的运行时.

@reus 不知道谁是半桶水,你可以看看`man 3 read`, EOF 是怎么确定的,
No data transfer shall occur past the current end-of-file. If the
starting position is at or after the end-of-file, 0 shall be returned.
If the file refers to a device special file, the result of subsequent
read() requests is implementation-defined.
所以 42,EOF 是怎么返回的?
go 的标准库设计的很没有品味, 很多东西都模模糊糊处理,在一些 corner case 就会出现很奇怪的行为.
go 缺少一种 rfc 机制,导致她的设计终究是跟着 Google 的需要而不是社区的需要走的,这也限制了她像 C 一样可以流行 50 年并且可以预料的再流行至少 20 年.

建议标题上标上 C++, const 的语义在不同语言中是不一样的,同时具有 immutable 和 compile time constant 两种语义,编译器能做出的优化也是不一样的.immutable 相对而言能做的优化更少,但是可以有效的避免一些 bug.
alias 分析理论上可行但是工程上很难做到,rustc 在启用 no alias 时 LLVM 会编译出错误的结果,而 C/C++不靠程序员主动标记很难得到积极的结果.

vscode 不同语言服务器的性能不一样的,拿 C++/Rust 写的语言服务器性能肯定强过 Java 写的,但 Nodejs 和 Python 写的就不好说了.单就 UI 而言 vscode 这个浏览器不会占用多少 CPU

速龙 200GE 都不如,也就和小红标 A10 上的那种老 GCN 一个水平的

mqtt over Websocket

dd if=/dev/urandom of=/dev/nvme0n1 bs=4M
大部分情况下文件系统撑不了几秒就会 panic

1.挂上开源协议,一般都有免责条款
2.1 是没有用的,不要在代码里写死或者透露出被爬的网站的信息.因为只有被爬的网站才会起诉你
3.由 2,你开发了一个爬虫框架,而不是爬某个特定网站的脚本,这时候危险性就大大降低了
4.我不是律师,上述均属扯蛋,可靠与否自行判断

有这种东西会直接被报为木马的

vscode 文件窗格的顶上不是有导航栏吗

ssh 开 root 登陆是很不安全的
开了 root 密码登陆就更不安全了,暴力无限试下去密码就破了.
应该换用非 root 账户+密钥登陆+fail2ban, 这样自己可以免密码登陆且他人无法暴力破解账户密码, 只需要让 /www/blog.git 允许非 root 账户可写就行

很多人不知道 RedHat 的稳定是什么意思
1. 有 bug 提交给工程师会修
2. 系统的 API 和 ABI 是稳定的,但是有可能会 backport 新功能
用 CentOS 是享受不到 1 的,那就考虑 2 是不是真的有用

这是直接从 electron 7 (chromium 78)升级到 electrom 9 (chromium 83)了吧

1.协程处理 IO 很快
协程不会让 IO 操作变快,但是可以在等待 IO 操作时执行其他协程,也就是提高了吞吐量
2.协程处理高并发很快
同 1, 吞吐量大了才能处理高并发
3.协程上下文开销很少
相较于 fork join 模式,线程池+有栈协程的开销更小,但是 Rust 的无栈协程才是无开销的模式
创建线程需要操作系统分配完整的栈+TCB, 而创建有栈协程只需要分配较小的栈+运行时自己调度,无栈协程在编译时直接变成状态机,运行时建立这个状态机就一直执行下去了,不需要分配栈.
4.协程占用资源很少
有栈协程会分配一块内存作为栈,比线程省资源

水深火热预定: https://github.com/github/gov-takedowns

@raaaaaar 楼主要输出到 pdf,现在 mdbook 好像没有支持生成 pdf 书签的后端