Kotlin可以从Rust中学到什么 - Cedric

在开始之前想重申一下，我的观点不是要在两种语言之间发起语言战争，也不是试图将一种语言变成另一种语言。我花了很多时间分析我想要讨论的特性，并自动排除了对一种语言非常有意义而在另一种语言中很荒谬的特性。例如，在 Rust 中要求垃圾收集是愚蠢的（因为它的主要主张是对内存分配的非常严格的控制）并且反过来，Kotlin 采用借用检查器是没有意义的，因为 Kotlin 收集垃圾是其主要诉求之一。
 
宏
我一直对语言中的宏有爱恨交加的关系，尤其是不卫生的。至少，宏应该完全集成在语言中，这需要两个条件：

• 编译器需要了解宏（例如，与 C 和 C++ 中的预处理器不同）。
• 宏需要拥有对静态类型 AST 的完全访问权限，并能够安全地修改此 AST。

let a = 2;
let b = 3;
dbg!(a + b);

[src\main.rs:158] a + b = 5

#![crate_type = "lib"]

#[test]
fn test_foo() {}

#[cfg(target_os = "macos")]
fn macos_only() {}

在上面的代码中，函数macos_only()只有在操作系统是 macOS 时才会被编译。
宏版本cfg()允许您向条件添加更多逻辑：

let machine_kind = if cfg!(unix) {
    "unix"
} else { … }

上面的代码是一个宏，这意味着它在编译时，编译器将完全忽略条件的任何部分。
您可能会想知道 Kotlin 中是否需要这样的功能是有道理的，我也问过自己同样的问题。
Rust 在多个操作系统上编译为本地可执行文件，如果您想在多个目标上发布工件，这使得这种条件编译非常必要。Kotlin 没有这个问题，因为它生成了在 JVM 上运行的操作系统中立的可执行文件。
尽管 Java 和 Kotlin 开发人员已经学会了不用预处理器，因为 C 预处理器给几乎每个使用过它的人留下了如此糟糕的印象，但在我的职业生涯中，也有一些情况能够进行条件编译，包括或排除源代码文件，甚至只是语句、表达式或函数，都会派上用场。
不管你在这场辩论中的立场如何，我不得不说我真的很喜欢 Rust 生态系统中两个截然不同的特性，宏和属性，能够协同工作以产生如此有用和多功能的特性。
 
扩展特性
扩展特征允许您“事后”使结构符合特征，即使您不拥有这些特征中的任何一个。最后一点需要重复：结构或特征是否属于您未编写的库并不重要。您仍然可以使该结构符合该特征。
例如，如果我们想在u8类型上实现一个函数last_digit()：

trait LastDigit {
    fn last_digit(&self) -> u8;
}

impl LastDigit for u8 {
    fn last_digit(&self) -> u8 {
        self % 10
    }
}

fn main() {
    println!("Last digit for 123: {}", 123.last_digit());
    // prints “3”
}

fun Type.function() {...}

同时提供一种更通用的机制来扩展函数和类型，但代价是语法稍微冗长一些。
 
Cargo交付
这可能令人惊讶，因为在 Gradle 中，Kotlin 拥有非常强大的构建和包管理器。这两个工具当然具有相同的功能表面区域，允许构建复杂的项目，同时还管理库下载和依赖项解析。
我认为Gradle 是一个更好的替代品的原因是因为它在声明性语法和命令式方面之间进行了清晰的分离。简而言之，标准的、通用的构建指令在声明性cargo.toml文件中指定，而临时的、更具程序性的构建步骤则直接在 Rust 中的名为 的文件中编写build.rs，使用 Rust 代码调用一个相当轻量级的构建 API。
相比之下，Gradle 一团糟。首先是因为它开始在 Groovy 中被指定，现在它支持 Kotlin 作为构建语言（并且这种转变仍在进行中，在它开始多年后），但也因为这两者的文档仍然非常糟糕
我所说的“糟糕”并不是指“缺乏”：有很多文档，只是……糟糕、不堪重负，其中大部分已经过时或已弃用，等等……需要从 StackOverflow 复制/粘贴数百行作为一旦你需要一些与众不同的东西。插件系统的定义非常松散，基本上允许所有插件访问 Gradle 内部结构中的任何内容。
显然，我对这个主题非常固执，因为我创建了一个受 Gradle 启发的构建工具，但使用了更现代的语法和插件解析方法（称为 Kobalt），但与此无关，我认为cargo设法取得了非常好的平衡在一个灵活的构建+依赖管理器工具之间，该工具充分涵盖了所有默认配置，而不会随着项目的增长而变得非常复杂。
 
u8, u16, ...
在 Rust 中，数字类型非常简单：u8是 8 位无符号整数，i16是 16 位有符号整数，f32是 32 位浮点数，等等……
这对我来说是一种清新的空气。在我开始使用这些类型之前，我从未完全确定我一直对 C、C++、Java 等定义这些类型的方式感到不舒服。每当我需要一个数字时，我都会使用int或Long作为默认值。在 C 中，我有时甚至long long没有真正理解其中的含义。
Rust 迫使我密切关注所有这些类型，然后，每当我尝试执行可能导致错误的强制转换时，编译器都会毫不留情地让我保持诚实。我真的认为所有现代语言都应该遵循这个约定。
 
编译器错误信息
并不是说 Kotlin 的错误消息很糟糕，但 Rust 确实在多个维度上在这里树立了新标准。
简而言之，以下是您可以从 Rust 编译器中得到的期望：

• 带有箭头、颜色、问题部分的清晰描述的 ASCII 图形。
• 简单的英语和详细的错误消息。
• 关于如何解决问题的建议。
• 相关文档的链接，您可以在其中找到有关该问题的更多信息。