挺好，内置类型总算支持泛型了。

公钥本身可以公开，但公钥具有 identify 特性，可能会被关联到你的其他身份。

@v2lhr 人在国内当然国内更不可信。
百度和 Google 哪个拿了你的个人信息危害更大？
当然也不是说国外一定可信，但不信任国外却信任腾讯就是笑话了。

@reus #117 搜 nil pointer language:go 还有 4 万个 issues 呢，这样比较没多大意义。

这玩意就像防火墙，谁都不能阻止你手动关了它作死，但比起完全没有保护措施你不能说它没用。

楼主也是个奇才，连国外都不信任，却信任腾讯。。

@reus Option<T>当然能解决空指针的问题，unwrap()是用户主动的，而 go 里指针全部可空，相当于在所有解引用操作时自动调用 unwrap()，当然是语言的问题。
rust 的类型系统就可以在编译时就确保你必须显式处理 None 的情况，无论是用 pattern match，组合器，还是调用 unwrap()告诉编译器我保证此值不空。不然你根本拿不出来里面的值。
两者最大的区别是，当你认为一个指针非空而对它进行解引用，它可能是空从而让你 nullpointerexception.
而 rust 只要你拿到 Option<T>里面的值，就可以确保它一定非空。如果你忘了处理，压根不会通过编译。
kotlin 里面也有区分 nullability 的类型系统，而 rust 直接通过 enum 就达到了同样的效果。

至于 checked exception，我上面说的是，它的好处是毫无疑问的，而它的问题（如导致接口无法向下兼容）使用 error type 也可以避免。

@reus io 这里是比较特别的情况，你一般封装的函数不会出现正确和错误的叠加态。
有问题是指会在某些 rare case 同时返回 nil，这种运行时错误难以排查，能够在编译时就解决当然要好的多。

unwrap()也不是语言的问题吧，你用 go 的库代码要是出错不上抛无脑 panic()不也是坑么。

每次拿函数 /方法返回值使用的时候都得一遍遍的复制 if err!=nil {return nil,err} 这怎么解决？

当然一般情况不会处理每一种错误，但能和不能还是有区别的。像你这样把其他错误抛上去，那上层呢？你多抛几个来源不通的错误，上层没法知道有哪些错误他可以处理，再往上抛，这样层层叠加。最后你根本没办法区分，最终最外层只能包个 try catch 那样记录个日志然后退出。
如王垠讲的那样 https://www.yinwang.org/blog-cn/2017/05/23/kotlin，checked exception 好处是毫无疑问的，而类型系统保证的 Error type 得到同样好处的同时却不像 chacked exception 那样在实践中有那么多问题。

@reus 首先，这个 interrupt 是因为 rust 的标准库接口暴露出了更多的底层复杂度，和语言的设计没太大关系。
如果用 tokio::io::AsyncReadExt 代替 std::io::Read 的话，就和 go 一样不需要考虑底层细节了。

至于 union type，绝大多数使用情况下，当你调用完一个函数，应该成功时返回结果，失败时返回错误（原因）。当你检查完 if err!=nil 之后，一般情况是认为 既然 err 是 nil，那 val 就不是 nil，如果这个函数写的有问题的话，就可能同时返回(nil,nil)，接下来你没有额外检查的话就会遭遇臭名昭著的"NullPointerException"。
要是同时检查 val 和 err 是否为 nil 的话，那就太过 verbose 了。
以及那个 check 语法糖也没实装，当嵌套调用函数 /方法的时候就得一遍遍的复制粘贴，这显然也是语言设计失败的地方。

而 union type 则从语言层面确保了这一点，而不是仅靠程序员的约定俗成，只要返回 Ok(val)，那 val 就能够确保不会是空。
nullable 是 go 里很有问题的一个方面，使用 union type Option<T>也能够很优雅的解决这个问题。

再说 error,go 的 error 类型也是比较残废的，你只知道它返回 error，却不知道可能返回哪些 error 。rust 除了 non_exhaustive 这种刻意让你 fallback 处理的情况外，是能保证你显式的处理（或显式的忽略）了每一种可能的错误，不会出现 unexpected error,与 Java 的 checked exception 有异曲同工之处。

我这里说的糟粕，主要是指语言设计层面上。goroutine 则可以说是 go 最大的亮点，可惜 tokio 没法抄过来，async 带来了大量的复杂度，远没有 goroutine 写的爽快。

@reus 所以 rust 就可以在一个循环里连续读，返回值为 0 为中止条件。

exhaustive 是编译器保证的，能确保当前情况确实是 exhausted，以后再加了编译会报错提醒你修改。
而 go 的错误类型就残废的多，没有办法保证你处理了每一种错误。
你当然可以不额外处理，有错就返回。go 你不看文档不也是直接 err!=nil 返回么。
额外处理的语法也比 go 要优雅：

loop {
match p.read(&mut buf){
Ok(0)=>break,
Ok(i)=>{//do something},
Err(ErrorKind::Interrupted)=>{//handle interrupt},
Err(e)=>{//handle other error}
}
}

@reus 绝大多数使用场景这两个值就是应该有一个空，而 go 没有机制保证这一点。成功就是成功出错就是出错，不能说执行了一半错了一半。这个 io.EOF 场景恰好就是体现 go 错误处理糟糕的一个地方，你不但要检查 err!=nil，还得检查 err!=io.EOF ，读完了和读不了显然得不同处理。
rust 里 Read::read(&mut self,buf:&mut [u8])->Result<usize> 遇到 EOF 直接返回当前已经读取的长度，下次再调用立即返回 0，其他种类的错误既可以通过带有 exhausted check 的 enum match 确保所有情况都显式处理，也可以直接?语法糖轻松向上抛，并且得益于类型系统还带有 Java 中 checked exception 等价的效果。

建议不要用闭源客户端，谁知道哪天作者就被喝茶收编了。

@reus 举个常见的场景，我想把一个（可能出错）的函数返回值作为参数传给另一个函数，如果出错就把错误传递上去：
go 你得这样：
val,err:=f1()
if err!=nil{
return nil,err
}
f2(val)

而 rust 直接：
f2(f1()?);
就可以了。

以及王垠提到的，没有任何机制能保证 err 和 val 一定一个是 nil 一个不是，全靠程序员约定俗成。明明 union type 能够完美表示，却非要用 tuple 。

@reus 那倒是说说错漏在哪里，就我看来除了类型后置无分隔符我觉得无所谓其他还是很赞同的。
其他可能还有争议，err!=nil 我觉得没什么好说的，能把 rust 的 enum 和 Result 抄过来也好不少。

量子超距通信只能用于加密，无法突破定域性。

err!=nil 绝对是 go 最大的糟粕之一，一个 union type 就能解决的问题非要搞个 tuple 出来。