- 主题:Rust 有点油腻
println! 里的感叹号是说明这个是“宏”，而不是“函数”。
宏和函数还是有很多区别的。Rust是在调用的时候明确区分这两者，符合Rust不隐藏的理念。
let x: u32 = 5，把类型放到变量名后面是有好处的（但具体好处我也说不清），新语言比如go也这么做。习惯就好。另外，大部分情况下是不需要写这个类型的，Rust都会推导出来类型的。
对于u32缩写，Rust的做法是，越常见越基础的名词，就缩写越短，比如 fn（而不是function）。原生整数类型这些属于最基本的概念了，就用最短的缩写。
不要抗拒。一旦接受，就没问题了。
--
FROM 1.94.148.*
吐槽，说明你觉得他不好。
但其实，不一定是他真的不好，而是他跟你之前学的东西不一样。
u32 和 unsigned short，哪个更好呢？
想象一下，如果你是先学的 u32，然后再看到 unsigned short，肯定也会吐槽的：这么常见的定义居然需要2个关键字凑起来？
【 在 namoamituofo 的大作中提到: 】
: 道理我都懂，就是忍不住吐槽一下。
: 你说到一个非常关键的问题，任何东西要想学的快，就要先从内心接受，甚至觉得他非常先进。
--
FROM 1.94.148.*
我个人理解，也不能处处都完全明确。编译器还是要聪明些，可以做些省略。
你觉得省略声明 更费脑子，那你可以写完整的声明。
有人觉得不写声明更简单，就可以省略声明。
另外，如果你写过rust的crate就会发现，为了通用性，会用到很多泛型，会导致一些类型非常复杂。但如果要求使用者也要都写出来，就很麻烦了。
比如：
let v = (0..10).collect();
要是完整写（这里还省略了Allocator）：
let v: Vec<i32> = <std::ops::Range<i32> as std::iter::Iterator>::collect(
<std::ops::Range<i32> as std::iter::IntoIterator>::into_iter(0..10)
);
这也还是let的推导。如果match enum的时候也这么写，那就太恐怖了。
【 在 namoamituofo 的大作中提到: 】
: 你对如下观点有何见解：
: 我看类型推导也是个多余，属于过度设计。推导是写的时候省事了，但读的时候，读者脑子里面还得有个线程，人肉充当编译器进行类型推导。没感觉高明在哪，虽然如此，但也还有底线，还管类型，总比弱类型语言负责点。
:
--
FROM 115.220.224.*
你可以网络搜索下 "rust why name expect"，有一些说明。
是有历史原因的。如果明白了历史原因，就能理解为什么这么叫。
当然我个人认为这个名字确实不直观。但无伤大雅。
【 在 namoamituofo 的大作中提到: 】
: io::stdin().read_line(&mut guess).expect("Failed to read line");
: 那你说说，这句读起来就像在期待失败，精妙在哪。改成onFailure或者干脆except，是不是更直观？
--
FROM 115.220.224.*
学新语言的几种可能的状态：
1. 学到什么算什么，不动脑子。
2. 边学边跟之前的语言对比：
2.1 不一样的就是丑，老子不学了。
2.2 不一样的就是丑，但忍一忍。
2.3 不一样的，发现还可以这样，涨知识了；实在想不明白的去搜索一下，明白其中的原因，涨知识了。
我第一次接触rust就是2.1，看了几章就放弃了。
后来又学就是2.2，学到半路觉得有意思了，就慢慢变成2.3了。
--
修改:hellowub FROM 115.220.224.*
FROM 115.220.224.*
我遇到过更好的例子。就是类型又长又复杂又有很多细节，如果省略就非常好。
但一时想不起来。这个vec的例子是让AI给的例子。
再比如 iter()的返回值的类型，写出来就很麻烦：
fn foo<T>(v: &[T]) where T: MyTrait {
let iter0 = v.iter(); // < 这里iter0的类型很难写出来，同时也没必要写出来
...
}
【 在 namoamituofo 的大作中提到: 】
: 这个例子很好，说明了极端情况下类型造成的代码难读。
: 能看出来这是你用“人肉编译器”推导出来的类型。这样做容易出错不说，还必须缓存在脑子里。放在纸面上尚且难以阅读，何况放在脑子里。
: 关于这行代码，至少人肉推导想多了，可以这样写：
: ...................
--
FROM 115.220.224.*
你的意思是，我聪明但没品味？
哈哈
【 在 namoamituofo 的大作中提到: 】
: 可以看出你是一个非常热爱技术的人，很羡慕你，能乐在其中。
: 我见过很多大神，怎么说呢，大神一定是聪明的，但不一定有品味，或者说一定没品味。因为他们已经满足于他们的聪明，不再追求品味了。想追求也求不得，因为编程语言就是挖土的铁锹，是干活的工具，本来就是丑的，不是用来审美的。
: 不管是一个工程的设计，还是一个语言的设计，过程中会出现大量的权衡行为。就是左右权衡，让一个丑的东西，到底是往左边丑一点，还是往右边丑一点，大神要根据产品的定位来做决策。最终弄出来一个凑合用的东西。
: ...................
--
FROM 115.220.224.*
这不是极端的例子。
还想到另外一个例子：
fn foo(stat: Arc<Mutex<Stat>>) {
let stat0 = stat.lock().unwrap();
stat0.method1();
stat0.method2();
}
这里的 stat0，看上去是 Stat类型，也是在当成 Stat 来用。很直观。
但其实 stat0 是 MutexGuard<'_, Stat> 。
要像下面这么写的话，就麻烦了（还要引入MutexGuard这个定义），也没必要：
let stat0: MutexGuard<'_, Stat> = stat.lock().unwrap();
【 在 namoamituofo 的大作中提到: 】
: 这个例子很好，说明了极端情况下类型造成的代码难读。
: 能看出来这是你用“人肉编译器”推导出来的类型。这样做容易出错不说，还必须缓存在脑子里。放在纸面上尚且难以阅读，何况放在脑子里。
: 关于这行代码，至少人肉推导想多了，可以这样写：
: ...................
--
FROM 115.220.224.*