感觉Rust就是低配版Java…… もっと見る
为了去GC……各种妥协现在都怀疑Rust是不是就是C的语法糖了……为了减少作者的工作量各种简陋，又想实现OOP……
昨天甚至看到为了实现null弄了个枚举- -!还说是为了防止怕有人未处理空指针错误……听起来不知道为什么老是想到那句：这不是错误，这是个特性
@TurnipG "实现 null“？不存在的，没有人想要 null。函数式用枚举处理多种可能性是很标准的做法， 是否可能为 null 是其中之一，变量的类型就标明了它是否有可能为空，空指针错误是不存在的。"修正 java 的错"的 kotlin 做法是一样的, 变量是否可 null 不用 if 判断，不用异常，而是当作变量的类型，不过 kotlin 可 null 的类型的写法是加一个问号
@TurnipG @wzhd 書裡不都寫著原因...
@TurnipG 1. 把nullable和非nullable在类型层面分开来这是在java界都很有共识的东西啊，Kotlin 的主要优势里就有这么一条，从Java 8开始JVM也在尝试往这个方向靠拢。换句话说，即使是Java那边也认同，存在null这才是个错误
2. Rust 从来没有想实现 OOP，只是类型系统很强大，足以模拟 OOP（使用 OOP 的 Pattern 写 Rust 反而是比较蛋疼的一件事情）
3. Maybe (Option) / Either (Result) 这两个东西在函数式语言里都存在很久了
4. Rust 不是为了去 GC，而是为了改变 C 这种底层语言的现状，i.e. 引入静态检查，同时避免引入太多的 overhead。也就是说它的起点是 C，而不是 Java
5. 就算 Rust 跟 Java 有关系那也是高配版 Java。。就 Java 那个破类型系统什么时候可以跟 Rust 这类语言相提并论了？Java 又什么时候可以脱 Runtime 作为 systems programming language了呢
@TurnipG 就是为了防止有人没处理空指针……整个思路就是让机器做各种检查来防止人出错……
感觉Rust就是低配版Java…… もっと見る
@TurnipG "实现 null“？不存在的，没有人想要 null。函数式用枚举处理多种可能性是很标准的做法， 是否可能为 null 是其中之一，变量的类型就标明了它是否有可能为空，空指针错误是不存在的。"修正 java 的错"的 kotlin 做法是一样的, 变量是否可 null 不用 if 判断，不用异常，而是当作变量的类型，不过 kotlin 可 null 的类型的写法是加一个问号