标签 Git 下的文章

Gopher的Rust第一课:Rust的依赖管理

本文永久链接 – https://tonybai.com/2024/06/16/gopher-rust-first-lesson-managing-deps

在上一章《Gopher的Rust第一课:Rust代码组织》中,我们了解了Rust的代码组织形式,知道了基于Cargo构建项目以及Rust代码组织是目前的标准方式,同时Cargo也是管理项目外部依赖的标准方法,而项目内部的代码组织则由Rust module来完成。

在这一章中,我们将聚焦Rust的依赖管理,即Cargo对外部crate依赖的管理操作。我将先介绍几种依赖的来源类型(来自crates.io或其他Package Registries、来自某个git仓库以及来自本地的crate等),然后说说Cargo依赖的常见操作,包括依赖的添加、升降版本和删除;最后,聊一下如何处理依赖同一个依赖项的不同版本。

作为Gopher,我们先来简略回顾一下Go的依赖管理要点,大家可以在学习Cargo依赖管理后自己做个简单的对比,看看各自的优缺点是什么。

5.1 Go依赖管理回顾

Go 1.11版本开始,Go引入了Go Modules以替代旧的GOPATH方式进行依赖管理。

我们可以使用go mod init命令初始化一个新的Go模块。go mod init会创建一个go.mod文件,该文件记录了当前项目的模块路径,并通过require directive记录了当前模块的依赖项以及版本:

require github.com/some/module v1.2.3

在开发过程中,我们也可以使用replace替换某个模块的路径,例如将依赖指向本地代码库进行调试:

replace example.com/some/module => ../local/module

或是通过replace将依赖指向某个特定版本的包。Go 1.18引入的Go工作区模式让依赖本地包的动作更为便利丝滑。

Go Modules支持语义版本控制(semver),版本号格式为vX.Y.Z(其中X是major,Y为minor,Z为patch)。当发生不兼容变化时X编号需要+1。Go创新性地使用了语义版本导入机制,通过在包导入路径上使用vX来支持导入同一个包的不同major版本:

import (
    "github.com/some/module"
    v2 "github.com/some/module/v2"
)

无论是Go代码中引入新依赖,还是通过go mod edit命令手工修改依赖(升级、更新版本或降级版本),通过go mod tidy这个万能命令都可以自动清理和整理依赖。 go module还支持使用go.sum文件来记录每个依赖项的精确版本和校验和,确保依赖的完整性和安全性。go.sum文件应当提交到版本控制系统中。

此外,go mod vendor支持将依赖项副本存储在本地,这可以使你的项目在没有网络连接的情况下构建,并且可以避免依赖项版本冲突。

Go并没有采用像Rust、Js那样的中心module registry,而是采用了分布式go proxy来实现依赖发现与获取,默认的goproxy为proxy.golang.org,国内Gopher可以使用goproxy.cn、goproxy.io以及几个大厂提供的GOPROXY。

注:更多关于Go module依赖管理的系统且详细的内容,可以看看我在极客时间“Go语言第一课”专栏中的两讲:06|构建模式:Go是怎么解决包依赖管理问题的?07|构建模式:Go Module的6类常规操作

接下来,我们正式进入Rust的依赖管理环节,我们先来看看Cargo依赖的来源。

5.2 Cargo依赖的来源

Rust的依赖管理系统中,Rust项目主要有以下几种依赖来源:

  1. 来自crates.io的依赖:这是Rust官方的crate registry,包含了大量开源的Rust库。
  2. 来自某个git仓库的依赖:可以从任何git仓库添加依赖,特别是在开发阶段或使用未发布的版本时非常有用。
  3. 来自本地的crate依赖:可以添加本地文件系统中的crate,便于在开发过程中引用本地代码。

接下来,我们就来逐一看看在一个Cargo项目中如何配置这三种不同来源的依赖。

5.2.1 来自crates.io的依赖

在Rust中,最常见的依赖来源是crates.io,这也是Rust官方维护的中心crate registry,我们可以通过cargo命令或手工修改Cargo.toml文件来添加这些依赖。我们用一个示例来说明一下如何为当前项目添加来自crates.io的依赖。

我们先用cargo创建一个名为hello_world的binary项目:

$cargo new hello_world --bin
     Created binary (application) `hello_world` package

$cat Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

//managing-deps/hello_world/src/main.rs
fn main() {
    println!("Hello, world!");
}

构建该项目,这与我们在《Gopher的Rust第一课:第一个Rust程序》一文中描述的别无二致:

$cargo build
   Compiling hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 1.07s

$./target/debug/hello_world
Hello, world!

现在我们改造一下main.rs代码,添加点“实用”代码(改自serde的example):

//managing-deps/hello_world/src/main.rs
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Debug)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    println!("Hello, world!");
    let point = Point { x: 1, y: 2 };

    // Convert the Point to a JSON string.
    let serialized = serde_json::to_string(&point).unwrap();

    // Prints serialized = {"x":1,"y":2}
    println!("serialized = {}", serialized);

    // Convert the JSON string back to a Point.
    let deserialized: Point = serde_json::from_str(&serialized).unwrap();

    // Prints deserialized = Point { x: 1, y: 2 }
    println!("deserialized = {:?}", deserialized);
}

然后我们通过cargo check命令检查一下源码是否可以编译通过:

$cargo check
    Checking hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
error[E0432]: unresolved import `serde`
 --> src/main.rs:1:5
  |
1 | use serde::{Deserialize, Serialize};
  |     ^^^^^ use of undeclared crate or module `serde`

error[E0433]: failed to resolve: use of undeclared crate or module `serde_json`
  --> src/main.rs:14:22
   |
14 |     let serialized = serde_json::to_string(&point).unwrap();
   |                      ^^^^^^^^^^ use of undeclared crate or module `serde_json`

error[E0433]: failed to resolve: use of undeclared crate or module `serde_json`
  --> src/main.rs:20:31
   |
20 |     let deserialized: Point = serde_json::from_str(&serialized).unwrap();
   |                               ^^^^^^^^^^ use of undeclared crate or module `serde_json`

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `hello_world` (bin "hello_world") due to 3 previous errors

cargo check提示找不到serde、serde_json两个crate。并且,cargo check执行后,多出一个Cargo.lock文件。由于此时尚未在Cargo.toml中添加依赖(虽然代码中明确了对serde和serde_json的依赖),Cargo.lock中还没有依赖package的具体信息:

$cat Cargo.lock
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3

[[package]]
name = "hello_world"
version = "0.1.0"

Rust是否可以像go module那样通过go mod tidy自动扫描源码并在Cargo.toml中补全依赖信息呢?然而并没有。Rust添加依赖的操作还是需要手动完成。

我们的rust源码依赖serde和serde_json,接下来,我们就需要在Cargo.toml中手工添加serde、serde_json依赖,当然最标准的方法还是通过cargo add命令:

$cargo add serde serde_json
      Adding serde v1.0.202 to dependencies.
             Features:
             + std
             - alloc
             - derive
             - rc
             - serde_derive
             - unstable
      Adding serde_json v1.0.117 to dependencies.
             Features:
             + std
             - alloc
             - arbitrary_precision
             - float_roundtrip
             - indexmap
             - preserve_order
             - raw_value
             - unbounded_depth

我们查看一下cargo add执行后的Cargo.toml:

$cat Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
serde = "1.0.202"
serde_json = "1.0.117"

我们看到在dependencies下新增了两个直接依赖信息:serde和serde_json以及它们的版本信息。

关于依赖版本,Cargo定义了的兼容性规则如下:

针对在1.0版本之前的版本,比如0.x.y,语义版本规范认为是处于初始开发阶段,公共API是不稳定的,因此没有明确兼容性语义。但Cargo对待这样的版本的规则是:0.x.y与0.x.z是兼容的,如果x > 0且y >=z。比如:0.1.10是兼容0.1.1的。而在1.0版本之后,Cargo参考语义版本规范确定版本兼容性。

基于上述的兼容性规则,在Cargo.toml中指定依赖版本的形式与语义有如下几种情况:

some_crate = "1.2.3" => 版本范围[1.2.3, 2.0.0)。
some_crate = "1.2" => 版本范围[1.2.0, 2.0.0)。
some_crate = "1" => 版本范围[1.0.0, 2.0.0)。

some_crate = "0.2.3" => 版本范围[0.2.3, 0.3.0)。
some_crate = "0.2" => 版本范围[0.2.0, 0.3.0)。
some_crate = "0" => 版本范围[0.0.0, 1.0.0)。

some_crate = "0.0" => 版本范围[0.0.0, 0.1.0)。
some_crate = "0.0.3" => 版本范围[0.0.3, 0.0.4)。

some_crate = "^1.2.3" => 版本范围[1.2.3]。

some_crate = "~1.2.3" => 版本范围[1.2.3, 1.3.0)。
some_crate = "~1.2" => 版本范围[1.2.0, 1.3.0)。
some_crate = "~1" => 版本范围[1.0.0, 2.0.0)。

Cargo还支持一些带有通配符的版本需求形式:

some_crate = "*" => 版本范围[0.0.0, )。
some_crate = "1.*" => 版本范围[1.0.0, 2.0.0)。
some_crate = "1.2.*" => 版本范围[1.2.0, 1.3.0)。

如果要限制最高版本范围,可以用带有多版本的需求形式:

some_crate = ">=1.2, < 1.5" => 版本范围[1.2.0, 1.5.0)。

有了版本范围后,Cargo初始就会使用该范围内的当前最大版本号版本作为依赖的最终版本。比如some_crate = "1.2.3",但当前some_crate的最高版本为1.3.5,那么Cargo会选择1.3.5的some_crate作为当前项目的依赖。

如果一个项目有两个依赖项同时依赖另外一个共同的依赖,比如(例子来自Cargo book):

# Package A
[dependencies]
bitflags = "1.0"

# Package B
[dependencies]
bitflags = "1.1"

那么A依赖bitflags的范围在[1.0.0, 2.0.0),B依赖bitflags的范围在[1.1.0, 2.0.0),这样如果当前bitflags的最新版本为1.2.1,那么Cargo会选择1.2.1作为bitflags的最终版本。这点与Go的最小版本选择(mvs)是不一样的,在这个示例情况下,Go会选择bitflags的1.1.0版本,即满足A和B的bitflags的最小版本即可。

后续当依赖的版本有更新时,可以执行cargo update升级依赖的版本到一个兼容的、更高的版本(体现在Cargo.lock文件中依赖的版本更新)。

Cargo.lock是锁定Cargo最终采用的依赖的版本的描述文件,这个文件由cargo管理,不要手动修改,这时的Cargo.lock文件如下:

$cat Cargo.lock
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3

[[package]]
name = “hello_world”
version = “0.1.0″
dependencies = [
 "serde",
 "serde_json",
]

[[package]]
name = “itoa”
version = “1.0.11″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “49f1f14873335454500d59611f1cf4a4b0f786f9ac11f4312a78e4cf2566695b”

[[package]]
name = “proc-macro2″
version = “1.0.83″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “0b33eb56c327dec362a9e55b3ad14f9d2f0904fb5a5b03b513ab5465399e9f43″
dependencies = [
 "unicode-ident",
]

[[package]]
name = “quote”
version = “1.0.36″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “0fa76aaf39101c457836aec0ce2316dbdc3ab723cdda1c6bd4e6ad4208acaca7″
dependencies = [
 "proc-macro2",
]

[[package]]
name = “ryu”
version = “1.0.18″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “f3cb5ba0dc43242ce17de99c180e96db90b235b8a9fdc9543c96d2209116bd9f”

[[package]]
name = “serde”
version = “1.0.202″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “226b61a0d411b2ba5ff6d7f73a476ac4f8bb900373459cd00fab8512828ba395″
dependencies = [
 "serde_derive",
]

[[package]]
name = “serde_derive”
version = “1.0.202″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “6048858004bcff69094cd972ed40a32500f153bd3be9f716b2eed2e8217c4838″
dependencies = [
 "proc-macro2",
 "quote",
 "syn",
]

[[package]]
name = “serde_json”
version = “1.0.117″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “455182ea6142b14f93f4bc5320a2b31c1f266b66a4a5c858b013302a5d8cbfc3″
dependencies = [
 "itoa",
 "ryu",
 "serde",
]

[[package]]
name = “syn”
version = “2.0.65″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “d2863d96a84c6439701d7a38f9de935ec562c8832cc55d1dde0f513b52fad106″
dependencies = [
 "proc-macro2",
 "quote",
 "unicode-ident",
]

[[package]]
name = “unicode-ident”
version = “1.0.12″
source = “registry+https://github.com/rust-lang/crates.io-index”
checksum = “3354b9ac3fae1ff6755cb6db53683adb661634f67557942dea4facebec0fee4b”

和go.sum类似(但go.sum并不指示依赖项采用的具体版本), Cargo.lock中对于每个依赖项都包括名字、具体某个版本、来源与校验和。

我们再用cargo check一下该项目是否可以编译成功:

$cargo check
   Compiling serde v1.0.202
   Compiling serde_json v1.0.117
    Checking ryu v1.0.18
    Checking itoa v1.0.11
    Checking hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
error: cannot find derive macro `Serialize` in this scope
 --> src/main.rs:3:10
  |
3 | #[derive(Serialize, Deserialize, Debug)]
  |          ^^^^^^^^^
  |
note: `Serialize` is imported here, but it is only a trait, without a derive macro
 --> src/main.rs:1:26
  |
1 | use serde::{Deserialize, Serialize};
  |                          ^^^^^^^^^

error: cannot find derive macro `Deserialize` in this scope
 --> src/main.rs:3:21
  |
3 | #[derive(Serialize, Deserialize, Debug)]
  |                     ^^^^^^^^^^^
  |
note: `Deserialize` is imported here, but it is only a trait, without a derive macro
 --> src/main.rs:1:13
  |
1 | use serde::{Deserialize, Serialize};
  |             ^^^^^^^^^^^

error[E0277]: the trait bound `Point: Serialize` is not satisfied
    --> src/main.rs:14:44
     |
14   |     let serialized = serde_json::to_string(&point).unwrap();
     |                      --------------------- ^^^^^^ the trait `Serialize` is not implemented for `Point`
     |                      |
     |                      required by a bound introduced by this call
     |
     = help: the following other types implement trait `Serialize`:
               bool
               char
               isize
               i8
               i16
               i32
               i64
               i128
             and 131 others
note: required by a bound in `serde_json::to_string`
    --> /Users/tonybai/.cargo/registry/src/rsproxy.cn-8f6827c7555bfaf8/serde_json-1.0.117/src/ser.rs:2209:17
     |
2207 | pub fn to_string<T>(value: &T) -> Result<String>
     |        --------- required by a bound in this function
2208 | where
2209 |     T: ?Sized + Serialize,
     |                 ^^^^^^^^^ required by this bound in `to_string`

error[E0277]: the trait bound `Point: Deserialize<'_>` is not satisfied
    --> src/main.rs:20:31
     |
20   |     let deserialized: Point = serde_json::from_str(&serialized).unwrap();
     |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `Point`
     |
     = help: the following other types implement trait `Deserialize<'de>`:
               bool
               char
               isize
               i8
               i16
               i32
               i64
               i128
             and 142 others
note: required by a bound in `serde_json::from_str`
    --> /Users/tonybai/.cargo/registry/src/rsproxy.cn-8f6827c7555bfaf8/serde_json-1.0.117/src/de.rs:2676:8
     |
2674 | pub fn from_str<'a, T>(s: &'a str) -> Result<T>
     |        -------- required by a bound in this function
2675 | where
2676 |     T: de::Deserialize<'a>,
     |        ^^^^^^^^^^^^^^^^^^^ required by this bound in `from_str`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `hello_world` (bin "hello_world") due to 4 previous errors

似乎是依赖包缺少某个feature。我们重新add一下serde依赖,这次带着必要的feature:

$cargo add serde --features derive,serde_derive
      Adding serde v1.0.202 to dependencies.
             Features:
             + derive
             + serde_derive
             + std
             - alloc
             - rc
             - unstable

然后再执行check:

$cargo check
   Compiling proc-macro2 v1.0.83
   Compiling unicode-ident v1.0.12
   Compiling serde v1.0.202
   Compiling quote v1.0.36
   Compiling syn v2.0.65
   Compiling serde_derive v1.0.202
    Checking serde_json v1.0.117
    Checking hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 8.50s

我们看到,当开启serde的derive和serde_derive feature后,项目代码就可以正常编译和运行了,下面是运行结果:

$cargo run
   Compiling itoa v1.0.11
   Compiling ryu v1.0.18
   Compiling serde v1.0.202
   Compiling serde_json v1.0.117
   Compiling hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 4.16s
     Running `target/debug/hello_world`
Hello, world!
serialized = {"x":1,"y":2}
deserialized = Point { x: 1, y: 2 }

注:feature是cargo提供的一种条件编译和选项依赖的机制,有些类似于Go build constraints,但表达能力和控制精细度要远超go build constraints,但其复杂度也远超go build constraints。在本章中,我们不对feature进行展开说明,更多关于feature的详细说明,请参见cargo feature参考手册

除了官方的crates.io,Cargo还支持来自其他非官方的Registry的依赖,比如使用企业私有crate registry,这个不在本章内容范围内,后续会考虑用专题的形式说明。

考虑crates.io在海外,国内Rustaceans可以考虑使用国内的crate源,比如使用rsproxy源的配置如下:

// ~/.cargo/config
[source.crates-io]
replace-with = 'rsproxy'

[source.rsproxy]
registry = "https://rsproxy.cn/crates.io-index"

[source.rsproxy-sparse]
registry = "sparse+https://rsproxy.cn/index/"

[registries.rsproxy]
index = "https://rsproxy.cn/crates.io-index"

[net]
git-fetch-with-cli = true

git-fetch-with-cli = true表示使用本地git命令去获取registry index,否则使用内置的git库来获取。

5.2.2 来自git仓库的依赖

有时候,我们可能需要依赖一个尚未发布到crates.io上的库,这时可以通过git仓库来添加依赖。当然,这一方式也非常适合一些企业内的私有git仓库上的依赖。在Go中,如果没有一些额外的IT设置支持,便很难拉取私有仓库上的go module

下面我们使用下面命令将Cargo.toml中的serde依赖改为从git repo获取:

$cargo add serde --features derive,serde_derive  --git https://github.com/serde-rs/serde.git
    Updating git repository `https://github.com/serde-rs/serde.git`
      Adding serde (git) to dependencies.
             Features:
             + derive
             + serde_derive
             + std
             - alloc
             - rc
             - unstable

更新后的Cargo.toml依赖列表变为了:

[dependencies]
serde = { git = "https://github.com/serde-rs/serde.git", version = "1.0.202", features = ["derive", "serde_derive"] }
serde_json = "1.0.117"

不过当我执行cargo check时报如下错误:

$cargo check
    Updating git repository `https://github.com/serde-rs/serde.git`
remote: Enumerating objects: 28491, done.
remote: Counting objects: 100% (6879/6879), done.
remote: Compressing objects: 100% (763/763), done.
remote: Total 28491 (delta 6255), reused 6560 (delta 6111), pack-reused 21612
Receiving objects: 100% (28491/28491), 7.97 MiB | 205.00 KiB/s, done.
Resolving deltas: 100% (20065/20065), done.
From https://github.com/serde-rs/serde
 * [new ref]                    -> origin/HEAD
 * [new tag]           v0.2.0     -> v0.2.0
 * [new tag]           v0.2.1     -> v0.2.1
 * [new tag]           v0.3.0     -> v0.3.0
 * [new tag]           v0.3.1     -> v0.3.1
 ... ...
 * [new tag]           v1.0.98    -> v1.0.98
 * [new tag]           v1.0.99    -> v1.0.99
   Compiling serde v1.0.202
   Compiling serde_derive v1.0.202 (https://github.com/serde-rs/serde.git#37618545)
   Compiling serde v1.0.202 (https://github.com/serde-rs/serde.git#37618545)
    Checking serde_json v1.0.117
    Checking hello_world v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/hello_world)
error[E0277]: the trait bound `Point: serde::ser::Serialize` is not satisfied
    --> src/main.rs:14:44
... ...

在serde的github issue中,这个问题似乎已经修正,但在我的环境下不知何故依旧存在。

在使用git来源时,我们也可以指定一个特定的分支、tag或者commit:

[dependencies]
serde = { git = "https://github.com/serde-rs/serde.git", branch = "next" }
# 或者
serde = { git = "https://github.com/serde-rs/serde.git", tag = "v1.0.104" }
# 或者
serde = { git = "https://github.com/serde-rs/serde.git", rev = "a1b2c3d4" }

5.2.3 来自本地的crate依赖

在开发过程中,我们还可能需要引用本地文件系统中的crate。在Go中,我们可以使用go mod的replace或者Go workspace来解决该问题。在Rust中,我们也可以通过下面方式来添加本地依赖:

$cargo add serde --features derive,serde_derive  --path ../serde/serde
      Adding serde (local) to dependencies.
             Features:
             + derive
             + serde_derive
             + std
             - alloc
             - rc
             - unstable

// Cargo.toml
[dependencies]
serde = { version = "1.0.202", features = ["derive", "serde_derive"], path = "../serde/serde" }

不过,和来自git一样,基于来自本地的crate依赖,cargo check也报和基于git的crate依赖同样的错误。

5.3 Cargo依赖常见操作

下面简要说说依赖的常见操作,以来自crates.io的依赖为例。

5.3.1 添加依赖

正如上面示例中我们演示的那样,我们可以通过cargo add来添加一个依赖,或者可以通过手工编辑Cargo.toml文件添加对应的配置。例如,添加一个源自crates.io的新依赖rand库:

[dependencies]
rand = "0.8"

5.3.2 升降版本

要升级某个依赖到兼容的最新版本,可以使用cargo update;如果升级到不兼容版本,需要先修改Cargo.toml中的版本需求。例如,将rand库升级到2.x版本:

[dependencies]
rand = "2.0"

然后运行cargo update,Cargo会根据新的版本号需求进行重新解析依赖。

当然要降级依赖的版本到一个兼容的版本,通常可能需要在版本需求中使用类似“^x.y.z”来精确指定版本;如果要降级到一个不兼容版本,和升级到不兼容版本一样,需要先修改Cargo.toml中的版本需求,然后运行cargo update,Cargo会根据新的版本号需求进行重新解析依赖。

5.3.3 删除依赖

删除一个依赖则十分容易,只需从Cargo.toml中移除或注释掉对应的依赖配置, 然后运行cargo build,Cargo会更新项目的依赖关系。

5.4 处理依赖同一个依赖项的不同版本

在某些情况下,不同的crate可能依赖同一个crate的不同版本,这也是编程语言中典型的钻石依赖问题!是一个常见的依赖管理挑战。它发生在一个依赖项被两个或更多其他依赖项共享时。比如:app依赖A、B ,而A、B又同时依赖C。

在这样的情况下,前面我们提过Go给出的解决方案包含三点:

  • 若A、B依赖的C的版本相同,那么选取这个相同的C版本即可;
  • 若A、B依赖的C的版本不同但兼容(依照semver规范),那么选取C满足A、B依赖的最小版本,这叫做最小版本选择;
  • 若A、B依赖的C的版本不同且不兼容,那么通过语义导入版本,最终app将导入C的不同版本,这两个版本将在app中共存。

那么在Rust项目中,Cargo又是如何处理的呢?我们通过一个示例分别来看看这三种情况,我们创建一个app的示例:

// 在rust-guide-for-gopher/managing-deps目录下
$tree -F app
app
├── A/
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── B/
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── C/
│   ├── Cargo.lock
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── Cargo.lock
├── Cargo.toml
└── src/
    └── main.rs

7 directories, 10 files

app是一个binary cargo project,它的Cargo.toml和src/main.rs内容如下:

// app/Cargo.toml
[package]
name = "app"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
A = { path = "./A", version = "0.1.0" }
B = { path = "./B", version = "0.1.0" }

// app/src/main.rs
fn main() {
    println!("Hello, world!");
    A::hello_from_a();
    B::hello_from_b();
}

我们看到:app依赖crate A和B,并且分别调用了两个crate的公共函数。

接下来,我们再来看看A和B的情况,我们分场景说明。

5.4.1 依赖C的相同版本

当A和B依赖C的相同版本时,这个不难推断cargo最终会为A和B选择同一个依赖C的版本。比如:

$cat A/Cargo.toml
[package]
name = "A"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C", version = "1.0.0" }

$cat B/Cargo.toml
[package]
name = "B"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C", version = "1.0.0" }

$cat A/src/lib.rs
pub fn hello_from_a() {
    println!("Hello from A begin");
    C::hello_from_c();
    println!("Hello from A end");
}

$cat B/src/lib.rs
pub fn hello_from_b() {
    println!("Hello from B begin");
    C::hello_from_c();
    println!("Hello from B end");
}

$cat C/Cargo.toml
[package]
name = "C"
version = "1.3.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

$cat C/src/lib.rs
pub fn hello_from_c() {
    println!("Hello from C 1.3.0");
}

在这里A和B对C的依赖都是version = "1.0.0",通过前面的讲解我们知道,这等价于C的版本范围为[1.0.0, 2.0.0)。而C目前的版本为1.3.0,那么Cargo就会为A和B都选择1.3.0版本的C。我们运行一下这个app程序:

$cargo run
... ...
Hello, world!
Hello from A begin
Hello from C 1.3.0
Hello from A end
Hello from B begin
Hello from C 1.3.0
Hello from B end

我们还可以通过cargo tree命令验证一下对A和B对C版本的依赖:

$cargo tree --workspace --target all --all-features --invert C

C v1.3.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/C)
├── A v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/A)
│   └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)
└── B v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/B)
    └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)

我们看到A和B都依赖了C的v1.3.0版本。

5.4.2 依赖C的两个兼容版本

现在我们修改一下A和B对C的依赖版本需求:

$cat A/Cargo.toml
[package]
name = "A"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C", version = "1.1.1" }

$cat B/Cargo.toml
[package]
name = "B"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C", version = "1.2.3" }

让A对C的依赖需求为1.1.1,让B依赖需求为1.2.3,这回我们再来运行一下cargo run和cargo tree:

$cargo run
... ...
Hello, world!
Hello from A begin
Hello from C 1.3.0
Hello from A end
Hello from B begin
Hello from C 1.3.0
Hello from B end

$cargo tree --workspace --target all --all-features --invert C

C v1.3.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/C)
├── A v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/A)
│   └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)
└── B v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/B)
    └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)

由于1.1.1和1.2.3是兼容版本,因此Cargo选择了兼容这两个版本的C当前的最高版本1.3.0。

5.4.3 依赖C的两个不兼容版本

现在我们来试验一下当A和B依赖的C版本不兼容时,Cargo会为A和B选择C的什么版本!由于是本地环境,我们无法在一个目录下保存两个C版本,因此我们copy一份当前的C组件,将拷贝重命名为C-1.3.0,然后将C下面的Cargo.toml和src/lib.rs修改成下面的样子:

$cat C/Cargo.toml
[package]
name = "C"
version = "2.4.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

$cat C/src/lib.rs
pub fn hello_from_c() {
    println!("Hello from C 2.4.0");
}

然后我们修改一下A和B的依赖,让他们分别依赖C-1.3.0和C:

$cat A/Cargo.toml
[package]
name = "A"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C-1.3.0", version = "1.1.1" }

$cat B/Cargo.toml
[package]
name = "B"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C = { path = "../C", version = "2.2.3" }

我们再来运行一下该app:

$cargo run
... ...
Hello, world!
Hello from A begin
Hello from C 1.3.0
Hello from A end
Hello from B begin
Hello from C 2.4.0
Hello from B end

我们看到cargo为A选择的版本是C v1.3.0,而为B选择的C版本是C v2.4.0,也就是说C的两个不兼容版本在app中可以同时存在。

让我们再来用cargo tree查看一下对C的依赖关系:

$cargo tree --workspace --target all --all-features --invert C

error: There are multiple `C` packages in your project, and the specification `C` is ambiguous.
Please re-run this command with one of the following specifications:
  C@1.3.0
  C@2.4.0

我们看到,cargo tree提示我们两个版本不兼容,必须明确指明是要查看哪个C版本的依赖,那我们就分别按版本查看一下:

$cargo tree --workspace --target all --all-features --invert C@1.3.0

C v1.3.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/C-1.3.0)
└── A v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/A)
    └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)

$cargo tree --workspace --target all --all-features --invert C@2.4.0

C v2.4.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/C)
└── B v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app/B)
    └── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/app)

5.4.4 直接依赖C的不同版本

在Go中我们可以通过语义导入版本实现在app中直接依赖同一个包的两个不兼容版本:

import (
    "github.com/user/repo"
    v2  "github.com/user/repo/v2"
)

在Rust中,是否也可以实现这一点?如果可以,又是如何实现的呢?答案是可以。至少我们可以通过使用Cargo的依赖别名功能来实现。我们建立一个名为dep_alias的示例,其目录结构如下:

$tree -F dep_alias
dep_alias
├── C/
│   ├── Cargo.lock
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── C-1.3.0/
│   ├── Cargo.lock
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── Cargo.lock
├── Cargo.toml
└── src/
    └── main.rs

5 directories, 9 files

在这个示例中,app依赖C-1.3.0目录下的C 1.3.0版本以及C目录下的C 2.4.0版本,下面是app/Cargo.toml和app/src/main.rs的代码:

// rust-guide-for-gopher/managing-deps/dep_alias/Cargo.toml

$cat Cargo.toml
[package]
name = "app"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
C_v1 = { path = "C-1.3.0", version = "1.0.0", package = "C" }
C_v2 = { path = "C", version = "2.3.0", package = "C" }

$cat src/main.rs

$cat src/main.rs
extern crate C_v1 as C_v1;
extern crate C_v2 as C_v2;

fn main() {
    C_v1::hello_from_c();
    C_v2::hello_from_c();
}

这里,我们为C的两个不兼容版本建立了两个别名:C_v1和C_v2,然后在代码中分别使用C_v1和C_v2,cargo会分别为C_v1和C_v2选择合适的版本,这里C_v1最终选择为1.3.0,而C_v2最终定为2.4.0:

$cargo run
Hello from C 1.3.0
Hello from C 2.4.0

由于包名依然是C,所以在使用cargo tree查看依赖关系时,依然要带上不同版本:

$cargo tree --workspace --target all --all-features --invert C@1.3.0
C v1.3.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/dep_alias/C-1.3.0)
└── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/dep_alias)

$cargo tree --workspace --target all --all-features --invert C@2.4.0
C v2.4.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/dep_alias/C)
└── app v0.1.0 (/Users/tonybai/Go/src/github.com/bigwhite/experiments/rust-guide-for-gopher/managing-deps/dep_alias)

5.5 小结

在这一章中,我们介绍了Rust中通过Cargo进行依赖管理的基本方法。

我们首先简要回顾了Go语言的依赖管理,特别是Go Modules的相关内容,如go.mod文件、版本控制机制等。

接着我们介绍了Rust中通过Cargo进行依赖管理的方法。Cargo依赖主要有三种来源:crates.io官方注册中心、Git仓库和本地文件系统。通过Cargo.toml文件和cargo命令,我们可以灵活添加、升级、降级或删除依赖项。文中还讲解了Cargo的版本兼容性规则和各种指定版本的语法。

针对依赖同一个库的不同版本的情况,我通过示例说明了Cargo的处理方式:如果版本相同或兼容,Cargo会选择满足要求的当前最高版本;如果版本不兼容,Cargo允许在项目中同时使用这些不兼容的版本,可以通过别名来区分使用。

总体来看,Cargo提供的依赖管理方式表达能力很强大,但相对于Go来说,还是复杂了很多,学习起来曲线要高很多,troubleshooting起来也不易,文中尚有一个遗留问题尚未解决,如果大家有解决方案或思路,可以在文章评论中告知我,感谢。

注:本文涉及的都是cargo依赖管理的基础内容,还有很多细节以及高级用法并未涉及。

本章中涉及的源码可以在这里下载。

5.6 参考资料


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) - https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 - https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go语言之父的反思:我们做对了什么,做错了什么

本文永久链接 – https://tonybai.com/2024/01/07/what-we-got-right-what-we-got-wrong

在《2023年Go语言盘点:稳中求新,稳中求变》和《Go测试的20个实用建议》两篇文章中,我都提到过已经退居二线的Go语言之父Rob PikeGo开源14周年的那天亲自在GopherCon Australia 2023上发表了“What We Got Right, What We Got Wrong”的主题演讲来回顾Go诞生以来的得与失。近期Rob Pike终于将这次演进的文字稿发布了出来GopherCon Australia也在油管上发布了这个演进的视频。Rob Pike的观点对所有Gopher都是极具参考价值的,因此在这篇博文中,我将Rob Pike的这次演讲稿翻译成中文,供大家参考(结合文字稿和视频),我们一起来领略和学习大师的观点。


这是2023年11月10日我在悉尼GopherConAU 2023会议上的闭幕演讲(视频),那一天也是Go开源14周年的日子。本文中穿插着演示文稿中使用的幻灯片。

介绍

大家好!

首先,我要感谢Katie和Chewy让我有幸为此次GopherConAU大会做闭幕演讲。


2009年11月10日

今天是2023年11月10日,Go作为开源项目推出14周年的纪念日。

2009年11月10日那天,加州时间下午3点(如果没记错的话),Ken Thompson、Robert Griesemer、Russ Cox、Ian Taylor、Adam Langley、Jini Kim和我满怀期待地看着网站上线。之后,全世界都知道我们在做什么了。

14年后的今天,有很多事情值得回顾。我想借此机会谈谈自那一天以来学到的一些重要经验。即使是最成功的项目,在反思之后,也会发现一些事情本可以做得更好。当然,也有一些事情事后看来似乎是成功的关键所在。

首先,我必须明确的是,这里的观点只代表我个人,不代表Go团队和Google。无论是过去还是现在,Go都是由一支专注的团队和庞大的社区付出巨大努力的结果。所以,如果你同意我的任何说法,请感谢他们。如果你不同意,请责怪我,但请保留你的意见。

鉴于本次演讲的题目,许多人可能期待我会分析语言中的优点和缺点。当然,我会做一些分析,但还会有更多内容,原因有几个。

首先,编程语言的好坏很大程度上取决于观点而不是事实,尽管许多人对Go或任何其他语言的最微不足道的功能都存在争论。

另外,关于换行符的位置、nil的工作方式、导出的大小写表示法、垃圾回收、错误处理等话题已经有了大量的讨论。这些话题肯定有值得讨论的地方,但几乎没什么是还没有被讨论过的。

但我要讨论的不仅仅是语言本身的真正原因是,语言并不是整个项目的全部。我们最初的目标不是创造一种新的编程语言,而是创造一种更好的编写软件的方式。我们对所使用的语言有意见——无论使用什么语言,每个人都是如此——但是我们遇到的基本问题与这些语言的特性没有太大关系,而是与在谷歌使用这些语言构建软件的过程有关。


T恤上的第一只Gopher

新语言的创建提供了探索其他想法的新路径,但这只是一个推动因素,而不是真正的重点。如果当时我正在工作的二进制文件不需要45分钟来构建
,Go语言就不会出现。但那45分钟不是因为编译器慢(因为它不慢),也不是因为它所用的语言不好(因为它也不差)。缓慢是由其他因素造成的。

我们想解决的就是这些因素:构建现代服务器软件的复杂性:控制依赖性、与人员不断变化的大型团队一起编程、可维护性、高效测试、多核CPU和网络的有效利用等等。

简而言之,Go不仅仅是一种编程语言。当然,它是一种编程语言,这是它的定义。但它的目的是帮助提供一种更好的方式来开发高质量的软件,至少与14多年前的我们的环境相比。

时至今日,这仍然是它的宗旨。Go是一个使构建生产软件更容易、更高效的项目。

几周前,当我开始准备这次演讲时,我只有一个题目,除此之外别无其他。为了激发我的思路,我在Mastodon上向人们征求意见。不少人给予了回复。我注意到了一种趋势:人们认为我们做错的事情都在语言本身,而我们做对的事情都在语言周边,比如gofmt、部署和测试等。事实上,我觉得这令人鼓舞。我们试图做的事情似乎已经产生了效果。

但值得承认的是,我们在早期并没有明确真正的目标。我们可能觉得这些目标是不言自明的。为了弥补这一缺陷,我在2013年的SPLASH会议上发表了一场题为《谷歌的Go语言:面向软件工程的语言设计》的演讲。


Go at Google

那场演讲和相关的博客文章可能是对Go语言为何而生的最好诠释。

今天的演讲是SPLASH演讲的后续,回顾了我们在构建语言之后所学到的经验教训,并且可以更广泛地应用于更大的图景。

那么……来谈谈一些教训。

首先,当然,我们有:

The Gopher

以Go Gopher吉祥物开始可能看起来是一个奇怪的起点,但Go gopher是Go成功的最早因素之一。在发布Go之前,我们就知道我们想要一个吉祥物来装饰周边商品——每个项目都需要周边商品——Renee French主动提出为我们制作一个这样的吉祥物。在这一点上,我们做得非常正确。

下面最早的Gopher毛绒玩具的图片:


The Gopher

这是Gopher的照片,它的第一个原型不太成功。


Gopher和它进化程度较低的祖先

Gopher是一个吉祥物,它也是荣誉徽章,甚至是世界各地Go程序员的身份标志。此时此刻,你正在参加一个名为GopherCon的会议,这是众多GopherCon会议中的一个。拥有一个从第一天就准备好分享信息的容易识别、有趣的生物,对Go的成长至关重要。它天真又聪明——它可以构建任何东西!


Gopher建造机器人(Renee French 绘图)

它为社区参与该项目奠定了基调,这是卓越的技术与真正的乐趣相结合的基调。最重要的是,Gopher是社区的一面旗帜,一面团结起来的旗帜,尤其是在早期,当Go还是编程界的新贵时。

这是几年前Gopher参加巴黎会议的照片,看看他们多兴奋!


巴黎的Gopher观众(Brad Fitzpatrick摄)

尽管如此,在知识共享署名许可(Creative Commons Attribution license)下发布Gopher的设计也许不是最好的选择。一方面,它鼓励人们以有趣的方式重新组合他,这反过来又有助于培养社区精神。


Gopher model sheet

Renee创建了一个“模型表”来帮助艺术家在保持其精神原貌的同时进行艺术创作。

一些艺术家利用这些特征制作了自己版本的Gopher并获得了乐趣;Renee和我最喜欢的版本是日本设计师@tottie的和游戏程序员@tenntennen的:


@tottie的Gopher


@tenntennen 的gopher

但许可证的“归属”部分常常会导致令人沮丧的争论,或者导致Renee的创作不属于她,也不符合原作的精神。而且,说实话,这种归属往往只是不情愿地得到尊重,或者根本没有得到尊重。例如,我怀疑@tenntennen是否因他的Gopher插图被使用而获得补偿或是得到承认。


gophervans.com: Boo!

因此,如果让我们重来一次,我们会认真思考确保吉祥物忠于其理想的最佳方法。维护吉祥物是一件很难的事,而且解决方案仍然难以捉摸。

但更多的是技术性的事情。

做的对的事情

这里有一份我认为我们在客观上做对了的事情的清单,特别是在回顾的时候。并不是每一个编程语言项目都做了这些事情,但清单中的每一件对Go的最终成功都至关重要。我会试着言简意赅,因为这些话题都已为人所熟知。

1. 语言规范(Specification)

我们从正式的语言规范开始。这不仅可以在编写编译器时锁定行为,还可以使多个编译器实现共存并就该行为达成一致。编译器本身并不是一个规范。你测试编译器的依据是什么?


Web上的Go语言规范

哦,顺便说一句,该规范的初稿是在这里编写的,位于悉尼达令港一栋建筑的18层。我们正在Go的家乡庆祝Go的生日。

2. 多种实现

Go有多个编译器实现,它们都实现相同的语言规范。有了规范就可以更容易地实现这一点。

有一天,伊恩·泰勒(Ian Taylor)发邮件通知我们,在阅读了我们的语言规范草案后,他自己编写了一个编译器,这让我们感到惊讶!

Subject: A gcc frontend for Go
From: Ian Lance Taylor
Date: Sat, Jun 7, 2008 at 7:06 PM
To: Robert Griesemer, Rob Pike, Ken Thompson

One of my office-mates pointed me at http://.../go_lang.html .  It
seems like an interesting language, and I threw together a gcc
frontend for it.  It's missing a lot of features, of course, but it
does compile the prime sieve code on the web page.

这的确令人兴奋,但更多的编译器实现也随之而来了,所有这些都因正式规范的存在而成为可能。


很多编译器

拥有多个编译器帮助我们改进了语言并完善了规范,并为那些不太喜欢我们类似Plan-9的业务方式的其他人提供了替代环境。稍后会详细介绍。如今有很多兼容的实现,这很棒!

3. 可移植性

我们使Go应用的交叉编译变得轻而易举,程序员可以在他们喜欢的任何平台上工作,并交付到任何需要的平台。使用Go可能比使用任何其他语言更容易达成这一点。很容易将编译器视为运行它的机器的本地编译器,但没有理由这么认为。打破这个假设具有重要意义,这对许多开发者来说都是新鲜事。


可移植性

4. 兼容性

我们努力使语言达到1.0版本的标准,然后通过兼容性保证将其固定下来,这对Go的采用产生了非常明显的影响!我不理解为什么大多数其他项目一直在抵制这样做。是的,保持强大兼容性的确需要付出成本,但它可以阻止功能特性停滞,而在这个几乎没有其他东西保持稳定的世界里,不必担心新版本的Go会破坏你的项目,这足以令人感到欣喜!


Go兼容性承诺

5. 标准库

尽管它的增长在某种程度上是偶然的,因为在一开始没有其他地方可以安装Go代码,但拥有一个坚实、制作精良的标准库,其中包含编写21世纪服务器代码所需的大部分内容,这是一个重大资产。在我们积累了足够的经验来理解还应该提供什么之前,它使整个社区都使用相同的工具包。这非常有效,并有助于防止出现不同版本的库,从而帮助统一社区。


标准库

6. 工具

我们确保该语言易于解析,从而支持工具构建。起初我们认为Go需要一个IDE,但易于构建工具意味着,随着时间的推移,IDE将会出现在Go上。他们和gopls一起做到了,而且他们非常棒。


工具

我们还为编译器提供了一套辅助工具,例如自动化测试、覆盖率和代码审查(code vetting)。当然还有go命令,它集成了整个构建过程,也是许多项目构建和维护其Go代码所需的一切。


快速构建

此外,Go获得了快速构建的声誉,这也没有什么坏处。

7. Gofmt

我将gofmt作为一个单独的项目从工具中拿出来,因为它是一个不仅在Go上而且在整个编程社区上留下了印记的工具。在Robert编写gofmt之前(顺便说一句,他从一开始就坚持这样做),自动格式化程序的质量不高,因此大多未被使用。


gofmt谚语

gofmt的成功表明了代码自动格式化可以做得很好,今天几乎每种值得使用的编程语言都有一个标准格式化程序。我们不再为空格和换行符争论,这节省了大量时间了,这也让那些花在定义标准格式和编写这段相当困难的代码实现格式自动化上的时间显得超值。

此外,gofmt还使无数其他工具成为可能,例如简化器、分析器甚至是代码覆盖率工具。因为gofmt的内容成为了任何人都可以使用的库,所以你可以解析程序、编辑AST,然后打印完美的字节输出,供人类和机器使用。

谢谢,罗伯特。

不过,恭喜你就够了。接下来,我们来谈谈一些更有争议的话题。

并发性

并发有争议吗?嗯,在我2002年加入谷歌的那年肯定有。John Ousterhout曾说过:线程很糟糕。许多人都同意他的观点,因为线程似乎非常难以使用。


John Ousterhout不喜欢线程

谷歌的软件几乎总是避免使用它们,可以说是彻底禁止使用,而制定这一禁令的工程师引用了Ousterhout的言论。这让我很困扰。自20世纪70年代以来,我一直在做类似的并发事情,有时候甚至没有意识到,在我看来这很强大。但经过反思,很明显Ousterhout犯了两个错误。首先,他的结论超出了他有兴趣使用线程的领域,其次,他主要是在抱怨使用笨拙的低级包如pthread之类的线程,而不是抱怨这一基本思想。

像这样混淆解决方案和问题是世界各地工程师常犯的错误。有时,提出的解决方案比它解决的问题更难,并且很难看到有更简单的路径。但我离题了。

根据经验,我知道有更好的方法来使用线程,或者无论我们选择怎么称呼它们,我甚至在Go语言出现之前就曾就此发表过演讲。


Newsqueak中的并发

但我并不孤单,其他许多语言、论文甚至书籍都表明,并发编程可以做得很好,不仅我知道这一点。它只是还没有在主流中流行起来,Go的诞生部分地就是为了解决这个问题。在那次臭名昭著的45分钟构建中,我试图向一个非线程二进制文件添加一个线程,这非常困难,因为我们使用了错误的工具。

回顾过去,我认为可以公平地说,Go在让编程界相信并发是一种强大工具方面发挥了重要作用,特别是在多核网络世界中,它可以比pthread做得更好。如今,大多数主流语言都对并发提供了很好地支持。


Google 3.0

另外,Go的并发版本在导致它出现的语言线中有些新颖,因为它使goroutine变得平淡无奇。没有协程,没有任务,没有线程,没有名称,只有goroutine。我们发明了“goroutine”这个词,因为没有适合的现有术语。时至今日,我仍然希望Unix的拼写命令可以学会它。

顺便说一句,因为我经常被问到,让我花一分钟时间谈谈async/await。看到async/await模型及其相关风格成为许多语言选择支持并发的方式,我有点难过,但它肯定是对pthreads的巨大改进。

与goroutine、channel和select相比,async/await对语言实现者来说更容易也更小,可以更容易地内建或后移植到现有平台中。但它将一些复杂性推回给了程序员,通常会导致Bob Nystrom所著名的“彩色函数”。


你的函数是什么颜色的

我认为Go表明了CSP这种不同但更古老的模型可以完美地嵌入到过程化语言中,没有这种复杂性。我甚至看到它几次作为库实现。但它的实现,如果做得好,需要显著的运行时复杂性,我可以理解为什么一些人更倾向于不在他们的系统中内置它。不管你提供什么并发模型,重要的是只提供一次,因为一个环境提供多个并发实现可能会很麻烦。Go当然通过把它放在语言中而不是库中解决了这个问题。

关于这些问题可能要讲整场演讲,但目前就这些吧。

并发的另一个价值在于,它使Go看起来像是全新的东西。如我所说,一些其他语言在之前已经支持了它,但它们从未进入主流,而Go对并发的支持是吸引初学者采用的一个主要因素,它吸引了以前没有使用过并发但对其可能性感兴趣的程序员。

这就是我们犯下两个大错误的地方。


耳语的Gopher(Cooperating Sequential Processes)

首先,并发很有趣,我们很高兴拥有它,但我们设想的使用案例大多是服务器相关的,意在在net/http等关键库中完成,而不是在每个程序的所有地方完成。当许多程序员使用它时,他们努力研究它如何真正帮助他们。我们应该一开始就解释清楚,语言中的并发支持真正带到桌面的是更简单的服务器软件。这个问题空间对许多人很重要,但并非所有尝试Go的人都是如此,这点指导不足是我们的责任。

相关的第二点是,我们用了太长时间来澄清并行和并发之间的区别——支持在多核机器上并行执行多个计算,以及一种组织代码的方式,以便很好地执行并行计算。


并发不是并行

无数程序员试图通过使用goroutine来并行化他们的代码以使其更快,但经常对结果中的速度降低感到困惑。仅当基础问题本质上是并行的时候,例如服务HTTP请求,并发代码才会通过并行化而变快。我们在解释这一点上做得很糟糕,结果让许多程序员感到困惑,可能还赶走了一些人。

为了解决这个问题,我在2012年Waza上给Heroku的开发者大会做了一个题为“并发不是并行”的演讲。这是一次很有趣的演讲,但它应该更早发生。

对此表示歉意。但好处仍然存在:Go帮助普及了并发性作为构建服务器软件的一种方式。

接口

很明显,接口与并发都是Go中与众不同的思想。它们是Go对面向对象设计的答案,采用最初关注行为的风格,尽管新来者一直在努力使结构体承担这一角色。

使接口动态化,无需提前宣布哪些类型实现了它们,这困扰了一些早期评论者,并且仍然恼火一小部分人,但它对Go培育的编程风格很重要。大部分标准库都是建立在它们的基础之上的,而更广泛的主题如测试和管理依赖也高度依赖于它们慷慨的“欢迎所有人”的天性。

我觉得接口是Go中设计最好的部分之一。

除了一些早期关于接口定义中是否应该包括数据的讨论之外,它们在讨论的第一天就已经成形。


GIF 解码器:Go接口的练习(Rob Pike和Nigel Tao 2011)

在这个问题上还有一个故事要讲。

在Robert和我的办公室里那著名的第一天,我们讨论了关于多态性应该怎么处理的问题。Ken和我从C语言中知道qsort可以作为一个困难的测试用例,所以我们三个人开始讨论用我们这种初具雏形的语言如何实现一个类型安全的排序例程(routine)。

Robert和我几乎同时产生了同样的想法:在类型上使用方法来提供排序所需的操作。这个概念很快发展成了一个想法,即值类型拥有作为方法定义的行为,一组方法可以提供函数可以操作的接口。Go的接口几乎立即就出现了。


sort.Interface

有一点没人经常提到:Go的sort函数是作为一个在接口上操作的函数实现的。这与大多数人熟悉的面向对象编程风格不同,但这是一个非常强大的想法。

这个想法对我们来说非常激动人心,它可能成为一个基础的编程构造,这令我们陶醉。当Russ Cox加入时,他很快指出了I/O如何完美地融入这个想法,标准库的发展非常迅速,在很大程度上依赖于三个著名的接口:空接口(interface{})、Writer和Reader,每个接口平均包含两个第三个方法。那些微小的方法对Go来说是惯用法,无处不在。

接口的工作方式不仅成为Go的一个显著特性,它们也成为我们思考库、泛型和组合的方式。这是让人兴奋的事情。

但我们在这个问题上停止讨论可能是一个错误。

你看,我们之所以走上这条路,至少在一定程度上是因为我们看到泛型编程太容易鼓励一种倾向于在算法之前首先关注类型的思考方式。过早抽象而不是有机设计。容器而不是函数。

我们在语言中正确定义了通用容器——map,切片,数组,channel——而不给程序员访问它们所包含的泛型。这可以说是一个错误。我们相信,我认为仍然正确的是,大多数简单的编程任务可以很好地由这些类型来处理。但有一些不能,语言提供的和用户可以控制的之间的障碍肯定困扰了一些人。

简而言之,尽管我不会改变接口的任何工作方式,但它们以需要十多年时间才能纠正的方式影响了我们的思维。Ian Taylor从一开始就推动我们面对这个问题,但在接口作为Go编程基石的情况下,这是相当困难的。

评论者经常抱怨我们应该使用泛型,因为它们“很简单”,在某些语言中可能确实如此,但接口的存在意味着任何新的多态形式都必须考虑到它们。找到一种可以与语言的其余部分很好地协同工作的前进方法需要多次尝试,几次中止的实现,以及许多小时、天数和周数的讨论。最终,在Phil Wadler的带领下,我们召集了一些类型理论家来提供帮助。即使在语言中有了可靠的泛型模型,作为方法集存在的接口也仍然存在一些遗留问题。


泛型版sort

如你所知,最终的答案是设计一个可以吸收更多多态形式的接口泛化,从“方法集合”过渡到“类型集合”。这是一个微妙但深刻的举措,大多数社区似乎都可以接受,尽管我怀疑抱怨声永远不会停止。

有时候要花很多年的时间来弄清楚一些事情,或者甚至弄清楚你并不能完全弄明白它。但你还是要继续前进。

顺便说一句,我希望我们有一个比“泛型”更好的术语,它起源于表示一种不同的数据结构中心多态风格。“参数多态”是Go提供的该功能的正确术语,这是一个准确的术语,但它难听。于是我们依然说“泛型”,尽管它不太恰当。

编译器

困扰编程语言社区的一件事是,早期的Go编译器是用C语言编写的。在他们看来,正确的方式是使用LLVM或类似的工具包,或者用Go语言本身编写编译器,这称为自举。我们没有做这两者中的任何一种,原因有几个。

首先,自举一种新语言要求至少其编译器的第一步必须用现有语言完成。对我们来说,C语言是显而易见的选择,因为Ken已经编写了C编译器,并且其内部结构可以很好地作为Go编译器的基础。此外,用自己的语言编写编译器,同时开发该语言,往往会产生一种适合编写编译器的语言,但这不是我们想要的语言。

早期的编译器工作良好,它可以很好地引导语言。但从某种意义上说,它有点奇怪,实际上它是一个Plan 9风格的编译器,使用旧的编译器编写思想,而不是新的思想,如静态单一赋值(SSA)。生成的代码平庸,内部不太漂亮。但它是务实高效的,编译器代码本身体积适中,对我们来说也很熟悉,这使得我们在尝试新想法时可以快速进行更改。一个关键步骤是添加自动增长的分段堆栈。这很容易添加到我们的编译器中,但是如果我们使用像LLVM这样的工具包,考虑到ABI和垃圾收集器支持所需的更改,将这种更改集成到完整的编译器套件中是不可行的。

另一个工作良好的区域是交叉编译,这直接来自原始Plan 9编译器套件的工作方式。

按照我们的方式行事,无论多么非正统,都有助于我们快速前进。有些人对这一选择感到冒犯,但这对当时的我们来说是正确的选择。


Go 1.5之后的Go编译器架构

对于Go 1.5版本,Russ Cox编写了一个工具,可以半自动将编译器从C转换为Go。到那时,语言已经完成,编译器导向的语言设计的担忧也就无关紧要了。有一些关于这个过程的在线演讲值得一看。我在2016年的GopherCon上做了一个关于汇编器的演讲,这在我毕生追求可移植性的过程中是一个高点。


Go汇编器设计(GopherCon 2016)

我们从C开始做了正确的事情,但最终将编译器翻译为Go,使我们能够将Go所具有的所有优势带到其开发中,包括测试、工具、自动重写、性能分析等。当前的编译器比原始编译器干净得多,并且可以生成更好的代码。但是,当然,这就是自举的工作原理。

请记住,我们的目标不仅仅是一种语言,而是更多。

我们不寻常的做法绝不是对LLVM或语言社区中任何人的侮辱。我们只是使用了最适合我们任务的工具。当然,今天有一个LLVM托管的Go编译器,以及许多其他应该有的编译器。

项目管理

我们从一开始就知道,要成功,Go必须是一个开源项目。但我们也知道,在弄清楚关键的思想和有一个工作的实现之前,私下开发会更高效。头两年对澄清我们在试图实现什么,而不受干扰,是必不可少的。

向开源的转变是一个巨大的改变,也很具教育意义。来自社区的投入是压倒性的。与社区的接触花费了大量的时间和精力,尤其是对Ian,不知怎么他找到时间来回答任何人提出的每一个问题。但它也带来了更多。我仍然惊叹在Alex Brainman的指导下,社区完全独立完成的Windows移植的速度。那很神奇。

我们花了很长时间来理解转向开源项目的影响,以及如何管理它。

特别是,公平地说,我们花了太长时间来理解与社区合作的最佳方式。本次演讲的一个主题是我们的沟通不足——即使我们认为我们正在进行良好沟通——由于误解和不匹配的期望,大量时间被浪费了。本可以做得更好。

但是,随着时间的推移,我们说服了社区中的至少那一部分和我们在一起的人,我们的一些想法,虽然与常见的开源方式不同,但具有价值。最重要的是我们坚持通过强制代码审查和对细节的穷尽关注来维护高质量代码


Mission Control (drawing by Renee French)

一些项目的工作方式不同,它们快速接受代码,然后在提交后进行清理。Go项目则相反,力图将质量放在第一位。我相信这是更有效的方式,但它将更多的工作推回社区,如果他们不理解其价值,他们就不会感到应有的欢迎。在这方面还有很多东西要学习,但我相信现在的情况已经好多了。

顺便说一句,有一个历史细节不是广泛为人知的。该项目使用过4个不同的内容管理系统:SVN、Perforce、Mercurial和Git。Russ Cox做了一份艰巨的工作,保留了所有历史,所以即使今天,Git仓库也包含了在SVN中做出的最早的更改。我们都认为保留历史很有价值,我要感谢他做了这项艰苦的工作。

还有一点。人们经常认为谷歌会告诉Go团队该做什么。这绝对不是真的。谷歌对Go的支持非常慷慨,但它不制定议程。社区的投入要大得多。谷歌内部有一个巨大的Go代码库,团队用它来测试和验证版本,但这是通过从公共仓库导入谷歌完成的,而不是反过来。简而言之,核心Go团队由谷歌支付薪水,但他们是独立的。

包管理

Go的包管理开发过程做得并不好。我相信,语言本身的包设计非常出色,并且在我们讨论的第一年左右的时间里消耗了大量的时间。如果你感兴趣的话,我之前提到的SPLASH演讲详细解释了它为什么会这样工作。

一个关键点是使用纯字符串来指定导入语句中的路径,从而提供了我们正确认为很重要的灵活性。但从只有一个“标准库”到从网络导入代码的转变是坎坷的。


修复云(Renee French 绘制)

有两个问题。

首先,我们这些Go核心团队的成员很早就熟悉Google的工作方式,包括它的monorepo(单一代码仓库)和每个人都在负责构建。但是我们没有足够的经验来使用具有大量包版本的包管理器以及尝试解决依赖关系图的非常困难的问题。直到今天,很少有人真正理解技术的复杂性,但这并不能成为我们未能从一开始就解决这些问题的借口。这尤其令人尴尬,因为我曾是一个失败项目的技术负责人,为谷歌的内部构建做类似的事情,我应该意识到我们面临的是什么。


deps.dev

我在deps.dev上的工作是一种忏悔。

其次,让社区参与帮助解决依赖管理问题的初衷是好的,但当最终设计出来时,即使有大量的文档和有关理论的文章,社区中的许多人仍然感到受到了轻视。


pkg.go.dev

这次失败给团队上了一课,让他们知道如何真正与社区互动,并且自此取得了很大的进步。

不过,现在事情已经解决了,新的设计在技术上非常出色,并且似乎对大多数用户来说效果很好。只是时间太长,而且道路崎岖不平。

文档和示例

我们事先没有得到的另一件事是文档。我们写了很多文档,并认为我们做得很好,但很快就发现社区想要的文档级别与我们的预期不同。


修理图灵机的Gopher(Renee French 绘图)

关键缺失的一部分是最简单函数的示例。我们曾以为只需说明某个东西的功能就足够了,但我们花费了太长时间才接受到展示如何使用它的价值更大。


可执行的例子

不过,我们已经吸取了教训。现在文档中有很多示例,大部分是由开源贡献者提供的。我们很早就做的一件事就是让它们在网络上可执行。我在2012年的Google I/O大会上做了一次演讲,展示了并发的实际应用,Andrew Gerrand 编写了一段可爱的Web goo,使得直接从浏览器运行代码片段成为可能。我怀疑这是第一次这样做,但Go是一种编译语言,很多观众以前从未见过这个技巧。然后该技术被部署到博客和在线包文档中。


Go playground

也许更重要的是我们对Go Playground的支持,这是一个免费的开放沙箱,供人们尝试,甚至开发代码。

结论

我们已经走了很长一段路。

回顾过去,很明显很多事情都做得对,并且它们都帮助Go取得了成功。但还有很多事情可以做得更好,重要的是要承认这些问题并从中学习。对于任何托管重要开源项目的人来说,双方都有教训。

我希望我对这些教训及其原因的历史回顾会有所帮助,也许可以作为对那些反对我们正在做的事情和我们如何做的人的一种道歉/解释。


GopherConAU 2023 吉祥物,作者:Renee French

但在推出 14 年后,我们终于来了。公平地说,总的来说这是一个非常好的地方。

很大程度上是因为通过设计和开发Go作为一种编写软件的方式(而不仅仅是作为一种编程语言)做出的决定,我们已经到达了一个新的地方。

我们到达这里的部分原因包括:

  • 一个强大的标准库,可实现服务器代码所需的大部分基础知识
  • 并发作为该语言的“一等公民”
  • 基于组合而不是继承的方法
  • 澄清依赖管理的打包模型
  • 集成的快速构建和测试工具
  • 严格一致的代码格式
  • 注重可读性而非聪明性
  • 兼容性保证

最重要的是,得益于令人难以置信的乐于助人且多元化的Gophers社区的支持。


多元化的社区(@tenntennen 绘图)

也许这些问题最有趣的结果是,无论是谁编写的Go代码的外观和工作原理都是一样的,基本上没有使用该语言的不同子集的派系,并且保证随着时间的推移代码可继续编译和运行。对于主要编程语言来说,这可能是第一次。

我们绝对做对了。

谢谢。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2024年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats