标签 Rust 下的文章

2023年的Rust与Go[译]

本文永久链接 – https://tonybai.com/2023/02/22/rust-vs-go-in-2023

本文译自《Rust vs Go in 2023》

注:从2022年下半年开始,我们研发团队的产品研发不再局限于云端,车端也是将来的一个重要方向。于是我除了继续对Go语言保持常规的高度关注之外,也逐步开始留意Rust语言的发展。


Rust和Go哪个更好?Go还是Rust?在2023年,你应该为你的下一个项目选择哪种语言,为什么?两者在性能、简单性、安全性、功能、规模和并发性等方面如何比较?它们的共同点是什么,它们有哪些根本性的不同?让我们在这个友好而公平的Rust和Go的比较中找到答案。

Rust和Go都很棒

首先,我必须要说的是,Go和Rust都是绝对优秀的编程语言。它们都是现代的、强大的、被广泛采用的编程语言,并且都提供出色的性能。

你可能读过一些说Go比Rust好的文章,或者相反。但这真的没有意义;每一种编程语言都代表了一系列的权衡和取舍。每种语言都有自己的优化重点,所以你对语言的选择应该由适合你的东西和你想用它解决的问题决定。

在这篇文章中,我将尝试告诉你何时使用Go是理想选择以及何时使用Rust更佳。我也会试着介绍一下这两种语言的本质(如果你愿意的话,就是Go和Rust的道)。

虽然它们在语法和风格上有很大不同,但Rust和Go都是构建软件的一流工具。接下来,让我们仔细看看这两种语言。

Go和Rust的相似之处

Rust和Go有很多共同点,这也是你经常听到它们一起被提及的原因之一。两种语言的共同目标是什么呢?

Rust是一种低级静态类型的多范式编程语言,专注于安全和性能。 – Gints Dreimanis

Go是一种开源的编程语言,可以轻松构建简单、可靠、高效的软件。 – go.dev

内存安全

Go和Rust都属于现代编程语言,它们的首要任务是内存安全。经过几十年对C和C++等旧语言的使用,我们可以清楚地看到,导致错误和安全漏洞的最大原因之一是不安全地或不正确地访问内存。

Rust和Go以不同的方式处理这个问题,但它们的目标都是在管理内存方面比其他语言更聪明、更安全,并帮助你写出正确高性能的程序。

快速、紧凑的可执行文件

Go和Rust都是编译型语言,这意味着你的程序被直接翻译成可执行的机器码,因此你可以以单一二进制文件形式来部署你的程序;与Python和Ruby等解释型语言不同,你不需要将解释器和大量的库和依赖关系与你的程序一起分发,这是一个很大的优点。这也使得Rust和Go的程序与解释型语言相比都非常快。

通用语言

Rust和Go都是强大的、可扩展的通用编程语言,你可以用它们来开发各种现代软件,从网络应用到分布式微服务,或者从嵌入式微控制器到移动应用程序。

两者都有优秀的标准库、繁荣的第三方生态系统以及巨大的商业支持和庞大的用户基础。它们都已经存在了很多年,并将在未来几年内继续被广泛使用。今天学习Go或Rust将是对你时间和精力的合理投资。

务实的编程风格

Go和Rust都不是以函数式编程为主的语言(例如像Scala或Elixir),也不是完全面向对象的语言(像Java和C#)。相反,虽然Go和Rust都有与函数式和面向对象编程相关的特性,但它们是务实的语言,旨在以最合适的方式解决问题,而不是强迫你采用特定的做事方式。

如果你喜欢函数式编程风格,你会在Rust中发现更多对这种风格的支持,因为Rust在语法特性数量上要比Go更多。

我们可以讨论什么是“面向对象”语言,但可以说C++、Java或C#用户所期望的面向对象编程风格在Go或Rust中都不存在。 – Jack Mott

规模化的开发

Rust和Go都有一些有用的特性,使它们适合于大规模的编程,不管是指大型团队,还是大型代码库,或者两者兼具。

例如,C语言的程序员们多年来一直在争论将括号放在哪里,以及代码应该用制表符还是空格缩进,而Rust和Go通过使用标准的格式化工具(Go为gofmt,Rust为rustfmt)使用规范的风格自动重写你的代码,完全消除了这些问题。

这并不是说这种特殊的风格本身有多好:而是Rust和Go的程序员都喜欢这种标准化

gofmt的风格是没有人喜欢的,但gofmt却是所有人的最爱。 – Rob Pike

两种语言的另一个高分领域是构建管道(pipeline)。两种语言都有优秀的、内置的、高性能的标准构建和依赖管理工具;不再需要与复杂的第三方构建系统搏斗,也不再需要每隔几年就学习一个新的系统。

对于早期职业生涯以Java和Ruby为背景的我而言,构建Go和Rust代码感觉就像从我的肩上卸下了一个不可能的重担。当我在谷歌工作时,遇到用Go编写的服务是一种解脱,因为我知道它很容易构建和运行。Rust也是如此,尽管我只在较小规模的Rust项目上工作过。我希望可无限配置的构建系统的时代已经过去了,所有语言都会有自己专门的构建工具,开箱即可使用。- 山姆-罗斯

Rust还是Go?

综上可知,这两种语言都设计得很好、很强大,那么你可能会想知道那些关于两门语言的“圣战”究竟是怎么回事(我也是)。为什么人们对“Go vs.Rust”如此大惊小怪,在社交媒体上大打出手,并且写长篇博文说只有傻瓜才会使用Rust,或者Go不是真正的编程语言,或者其他什么。

这可能会让他们感觉好些,但这并不能完全帮助你,因为你正试图决定在你的项目中使用哪种语言,或者你应该学习哪种语言来推动你的编程生涯。一个明智的人不会根据谁喊得声最大来做出重要的选择。

现在让我们继续我们成熟的讨论,看看在某些领域,一个有理智的人可能更喜欢哪一种语言。

Go与Rust的性能对比

我们已经说过,Go和Rust都能生产出高性能的程序,因为它们被编译成了本地机器代码,而不必通过解释器或虚拟机。

然而,Rust的性能尤其突出。它可以与C和C++相媲美,这两种语言通常被认为是性能最高的编译语言,但与这些老语言不同的是,Rust还提供了内存安全和并发安全,并且基本上不会给执行速度上带去没有任何开销。Rust还允许你创建复杂的抽象,而不需要在运行时付出任何性能上的代价。

相比之下,尽管Go程序的性能也非常好,但Go主要是为开发速度(包括编译)而设计的,而不是执行速度。Go程序员更倾向于清晰的代码而不是快速的代码

Go编译器也不会花很多时间去尝试生成最有效的机器代码;它更关心的是快速编译大量代码。所以Rust通常会在运行时基准测试中击败Go。

Rust的运行时性能也是一致和可预测的,因为它不使用垃圾收集。Go的垃圾收集器非常高效,并且经过优化,使其“STW(停止世界)”的停顿时间尽可能短(每一个新的Go版本都会越来越短)。但是垃圾收集不可避免地在程序的行为方式中引入了一些不可预测的因素,这在某些应用中可能是一个严重的问题,例如嵌入式系统。

因为Rust旨在让程序员完全控制底层硬件,所以有可能将Rust程序优化到相当接近机器的最大理论性能。这使得Rust在执行速度胜过所有其他考虑因素的领域是一个很好的选择,比如游戏编程、操作系统内核、网络浏览器组件和实时控制系统。

简单性

如果没有人能够弄清楚如何使用一种编程语言,那么这种语言有多快也无所谓。Go语言是为了应对C++等语言不断增长的复杂性而特意设计的;它的语法非常少,关键字也非常少,事实上,功能特性也很少。

这意味着学习Go语言不需要很长时间,就可以用它来编写有用的程序。

Go是非常容易学习的。我知道这是一个经常被吹捧的好处,但我真的很惊讶于我能够如此迅速地提高工作效率。多亏了这个语言、文档和工具,我在两天后就写出了有趣的、可提交的代码。 – 一个Rust程序员对Go的早期印象

这里的关键词是简单性。当然,简单并不等同于容易,但是小而简单的语言比大而复杂的语言更容易学习。Go语言没有提供那么多不同的方法来做一件事情,所以所有写得好的Go代码往往看起来都一样。快速学习一个不熟悉的服务并理解它在做什么很容易。

fmt.Println("Gopher's Diner Breakfast Menu")
for dish, price := range menu {
    fmt.Println(dish, price)
}

在我的代码俱乐部视频系列中,我正是这样做的:从GitHub上半随机地挑选Go项目,并与一群Go初学者一起探索它们,看看我们能理解多少的代码。结果总是比我们预期的要多。

虽然核心语言很小,但Go的标准库却非常强大。这意味着你的学习曲线也需要包括你需要的标准库的部分,而不仅仅是Go语法。

另一方面,将功能从语言中转移到标准库中,意味着你可以只专注于学习与你现在相关的库。

Go也是为大规模的软件开发而设计的,支持有大型代码库的大型团队。在这种情况下,新的开发人员能够尽快上手是非常重要的。出于这个原因,Go社区十分看重:简单、明显、常规、直接的程序

使用Go,你可以快速完成工作。Go是我所使用过的生产力最高的语言之一。它的口号是:今天解决实际问题。 – 马蒂亚斯-恩德勒

特性

Rust比其他几种编程语言支持更多的复杂语法特性,因此,你可以用它实现更多。 – devathon

Rust是专门设计用来帮助程序员用最少的代码做最多的事情,它包括很多强大而有用的功能特性。例如,Rust的match功能可以让你以十分简洁地方式写出灵活的、富有表现力的逻辑:

fn is_prime(n: u64) -> bool {
    match n {
        0...1 => false,
        _ => !(2..n).any(|d| n % d == 0),
    }
}

因为Rust做了很多事情,这意味着有很多东西需要学习,特别是在开始的时候。但这没关系:在C++或Java中也有很多东西要学,而且你不会得到Rust的高级特性,比如内存安全。

批评Rust是一种复杂的语言忽略了一点:它被设计成具有表现力,这意味着有很多功能,而在许多情况下,这正是你想要的编程语言。

当然,Rust有一个学习曲线,但一旦你开始使用它,你就会好起来。

对于那些准备接受更复杂的语法和语义(以及可能更高的可读性成本)以换取最大可能的性能的程序员来说,Rust将与C++和D语言争夺思想份额。 – 戴夫-切尼

虽然Rust采用了Go的一些特性,而Go也在采用Rust的一些特性(尤其是泛型),但可以说Rust的特性很重,而Go的特性相对较轻。

并发

大多数语言都对并发编程(同时做多件事情)有某种形式的支持,但Go从一开始就是为这项工作而设计的。Go不使用操作系统的线程,而是提供了一个轻量级的替代方案:goroutine

每个goroutine是一个独立执行的Go函数,Go调度器会将其映射到其控制下的一个操作系统线程中。这意味着调度器可以非常有效地管理大量并发的goroutine,只使用有限的操作系统线程。

因此,你可以在一个程序中运行数百万个并发的goroutine,而不会产生严重的性能问题。这使得Go成为高规模并发应用程序的完美选择,如网络服务器和微服务。

Go还具有快速、安全、高效的功能特性,可以使用channel让goroutines进行通信和共享数据。Go的并发支持感觉设计得很好,使用起来也很愉快。

一般来说,对并发程序进行推断是很难的,而且在任何语言中建立可靠、正确的并发程序都是一个挑战。但由于它从一开始就内置于语言中,而不是事后才想到的,Go中的并发编程是最简单、最完整的。

Go语言可以很容易地建立一个很好的多因素的应用程序,充分利用并发性,同时作为一组微服务进行部署。Rust也可以做这些事情,但可以说它更难。 在某些方面,Rust对防止与内存有关的安全漏洞的痴迷意味着程序员必须不遗余力地执行那些在其他语言(包括Go)中会更简单的任务。 – Sonya Koptyev

相比之下,Rust中的并发故事是非常新的,而且还在稳定中,但它正处于非常积极的开发中,所以请关注这个领域。例如,Rust的rayon库提供了一种非常优雅和轻量级的方式来将顺序计算转化为并行计算。

拥有goroutines和使用channel的轻量级语法真的很好。这真的显示了语法的力量,这些小细节使并发编程比其他语言感觉好得多 – 一个Rust程序员对Go的早期印象

虽然在Rust中实现并发程序可能不那么简单,但还是有可能的,而且这些程序可以利用Rust的安全保证。

一个很好的例子是标准库的Mutex类:在Go中,你可以忘记在访问某些东西之前获得一个Mutex锁,但Rust不会让你这样做。

Go专注于将并发性作为一个一等公民的概念。这并不是说你不能在Rust中找到Go的面向actor的并发性,但这是留给程序员的一个练习。 – Dave Cheney

安全

我们在前面看到,Go和Rust都以不同的方式来防止一大类与内存管理有关的常见编程错误。但是Rust尤其努力确保你不会做一些你不想做的不安全的事情。

Rust的编译器非常严格和学究派,它检查你使用的每个变量和你引用的每个内存地址。它避免了可能的数据竞争条件,并告知你未定义的行为。并发和内存安全问题在Rust的安全子集中根本不可能发生。 – 为什么是Rust?

这将使Rust编程成为与几乎所有其他语言不同的体验,而且一开始可能是一种挑战。但对很多人来说,这种辛苦是值得的。

对我来说,Rust的关键优势是一种感觉,即编译器是我的后盾,不会让它可能检测到的任何错误通过(说真的,有时感觉就像魔法一样)。 – Grzegorz Nosek

包括Go在内的许多语言都有帮助程序员避免错误的设施,但Rust将这一点提高到了一个新的水平,因此可能不正确的程序甚至不会被编译。

有了Rust,库程序员有很多工具来防止他/她的用户犯错。Rust让我们有能力说,我们拥有一块特定的数据;其他东西不可能声称拥有,所以我们知道没有其他东西能够修改它。我想不出以前有什么时候我被赋予过这么多工具来防止意外的误用。这是一种奇妙的感觉。 – 山姆-罗斯

“与借用检查器(borrow checker)斗争”是Rust程序员新手的常见综合症,但在大多数情况下,它所发现的问题是你的代码中真正的bug(或至少是潜在的bug)。它可能会迫使你从根本上重构你的程序,以避免遇到这些问题;而当正确性和可靠性是你的首要任务时,这是件好事。

一个不改变你编程方式的语言有什么意义呢?当你用其他语言工作时,Rust所教授的关于安全的课程也是有用的。

如果你选择了Rust,通常你需要该语言提供的保证:针对空指针和数据竞争的安全,可预测的运行时行为,以及对硬件的完全控制。如果你不需要这些功能,Rust可能是你下一个项目的糟糕选择。这是因为这些保证是有代价的:入门时间。你需要戒掉坏习惯,学习新概念。有可能的是,当你开始的时候,你会经常和借用检查器斗争。 – Matthias Endler

你觉得Rust的编程模型有多大的挑战性,可能取决于你以前有哪些其他语言的经验。Python或Ruby程序员可能会发现它的限制性;其他人会很高兴。

如果你是一个花了几周的时间来追寻内存安全漏洞的C/C++程序员,你会非常欣赏Rust。”与借用检查器斗争”变成了”编译器可以检测到这个?酷!” -Grzegorz Nosek

规模化

今天的服务器程序由数千万行代码组成,由数百甚至数千名程序员进行构建,而且每天都在更新。Go的设计和开发是为了使在这种环境中工作更有成效。Go的设计考虑包括严格的依赖性管理,随着系统的发展,软件架构的适应性,以及组件之间的健壮性。 – Rob Pike

当你一个人或在小团队中处理问题时,选择简单的语言还是功能丰富的语言是一个偏好的问题。但是当软件越来越大,越来越复杂,团队越来越大时,差异就开始显现出来了。

对于大型应用程序和分布式系统来说,执行速度不如开发速度重要:像Go这样刻意简化的语言可以减少新开发人员的启动时间,并使他们更容易处理大型代码库的工作。

有了Go,作为初级开发者更容易提高工作效率,而作为中级开发者则更难引入会导致后续问题的脆弱抽象。由于这些原因,Rust在企业软件开发方面不如Go有说服力。 – Loris Cro

当涉及到大型的软件开发时,清晰的比聪明的好。Go的局限性实际上使它比Rust等更复杂和强大的语言更适合企业和大机构。

Rust和Go的不同点

虽然Rust和Go都是流行的、现代的、广泛使用的语言,但它们并不是真正的竞争对手,因为它们故意针对的是完全不同的使用情况。

Go的整个编程方法与Rust的完全不同,每一种语言都适合一些人,同时也会刺激另一些人。这完全没问题,如果Rust和Go都能以或多或少相同的方式做同样的事情,我们就不会真的需要两种不同的语言。

那么,我们是否可以通过发现Rust和Go所采取的截然不同的方法来了解它们各自的本性呢?让我们拭目以待。

垃圾回收

“要不要垃圾回收”是一个没有正确答案的问题。垃圾回收,以及一般的自动内存管理,使得开发可靠、高效的程序变得快速和容易,对于一些人来说,这至关重要。

但也有人说,垃圾回收及其性能开销和停顿,使程序在运行时表现得不可预测,并引入了不可接受的延迟。争论还在继续。

Go是一种与Rust非常不同的语言。虽然两者都可以被模糊地描述为系统语言或C语言的替代品,但它们有不同的目标和应用、语言设计的风格以及优先级。垃圾回收是一个真正巨大的区别。Go中的GC使语言更简单,更小,更容易推理。在Rust中没有GC会让它变得非常快(尤其是当你需要保证延迟,而不仅仅是高吞吐量的时候),并且可以实现Go中不可能实现的功能和编程模式(或者至少是在不牺牲性能的情况下)。 – PingCAP

接近机器

计算机编程的历史是一个越来越复杂的抽象的故事,它让程序员在解决问题时不用太担心底层机器的实际运作。

这使得程序更容易编写,也许更容易移植。但是对于许多程序来说,对硬件的访问以及对程序执行方式的精确控制更为重要。

Rust的目标是让程序员“更接近机器”,有更多的控制权,但Go抽象了架构细节,让程序员更接近问题。

两种语言都有不同的适用范围。Go在编写微服务和典型的”DevOps”任务方面表现出色,但它不是一种系统编程语言。Rust对于那些看重并发性、安全性和性能的任务中更强;但它的学习曲线比Go更陡峭。 – Matthias Endler

必须运行更快

许多人同意,对于大多数程序来说,性能不如可读性重要。但当性能确实重要时,它真的很重要。Rust做了一些设计上的权衡,以达到尽可能好的执行速度。

相比之下,Go更关注简单性,它愿意为此牺牲一些(运行时)性能。但是Go的构建速度是无可匹敌的,这对于大型代码库来说是非常重要的。

Rust比Go快。在基准测试中,Rust更快,在某些情况下,甚至是数量级的快。但在你选择用Rust写所有东西之前,考虑一下Go在许多基准测试中并不落后于它,而且它仍然比Java、C#、JavaScript、Python等快得多。如果你需要的是顶级的性能,那么选择这两种语言中的任何一种,你都会在游戏中领先。如果你正在构建一个处理高负载的网络服务,你希望能够在纵向和横向上进行扩展,那么这两种语言都会非常适合你。- 安德鲁-拉德

正确性

另一方面,如果一个程序不需要正常工作的话,它可以任意地快。大多数代码不是为长期而写的,但有些程序能在生产中运行多长时间往往是令人惊讶的:在某些情况下,可以保持几十年。

在这种情况下,值得在开发中多花一点时间,以确保程序的正确性、可靠性,并在未来不需要大量的维护。

Go和Rust都旨在帮助你编写正确的程序,但方式不同。例如,Go提供了一个极好的内置测试框架,而Rust则专注于使用其借用检查器消除运行时的错误。

我认为。Go适用于明天必须交付的代码,而Rust适用于必须在未来五年内保持运行不动的代码。 – Grzegorz Nosek

虽然Go和Rust对于任何严肃的项目来说都是很好的选择,但是让自己尽可能地了解每种语言及其特点是一个好主意。

归根结底,别人怎么想并不重要:只有你能决定哪种语言适合你和你的团队。

如果你想加快开发速度,也许是因为你有许多不同的服务需要编写,或者你有一个庞大的开发团队,那么Go是你的首选语言。Go把并发性作为第一等公民给你,并且不容忍不安全的内存访问(Rust也是如此),但不强迫你管理每一个细节。Go是快速和强大的,但它避免了使开发者陷入困境,而是专注于简单性和统一性。如果在另一方面,拧出每一盎司的性能是必要的,那么Rust应该是你的选择。 – 安德鲁-拉德

结论

我希望这篇文章能让你相信Rust和Go都值得你认真考虑。如果可能的话,你应该争取在这两种语言中至少获得一定程度的经验,因为它们对你的任何技术职业都会有极大的帮助,甚至如果你仅把编程作为一种业余爱好的话。

如果你只有时间投资学习一门语言,在你将Go和Rust用于各种不同类型的大小程序之前,不要做出最终决定。

而编程语言的知识实际上只是成为一名成功的软件工程师的一小部分。到目前为止,你需要的最重要的技能是设计、工程、架构、沟通和协作。如果你在这些方面表现出色,无论你选择哪种语言,你都会成为一名优秀的软件工程师。学习愉快!


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,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://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

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

Go 1.20中值得关注的几个变化

本文永久链接 – https://tonybai.com/2023/02/08/some-changes-in-go-1-20

美国时间2023年2月1日,唯一尚未退休的Go语言之父Robert Griesemer代表Go核心开发团队在Go官博撰文正式发布了Go 1.20版本。就像Russ Cox在2022 GopherCon大会所说的那样:Go2永不会到来,Go 1.x.y将无限延续

注:似乎新兴编程语言都喜欢停留在1.x.y上无限延续,譬如已经演化到1.67版本的Rust^_^。

《Go,13周年》之后,Go 1.20新特性在开发主干冻结(2022.11)之前,我曾写过一篇《Go 1.20新特性前瞻》,对照着Go 1.20 milestone中内容,把我认为的主要特性和大家简单过了一遍,不过那时Go 1.20毕竟没有正式发布,前瞻肯定不够全面,某些具体的点与正式版本可能也有差异!现在Go 1.20版本正式发布了,其Release Notes也补充完整了,在这一篇中,我再来系统说说Go 1.20版本中值得关注的那些变化。对于在前瞻一文中详细介绍过的特性,这里不会再重复讲解了,大家参考前瞻一文中的内容即可。而对于其他一些特性,或是前瞻一文中着墨不多的特性,这里会挑重点展开说说。

按照惯例,我们依旧首先来看看Go语法层面都有哪些变化,这可能也是多数Gopher们最为关注的变化点。

一. 语法变化

Go秉持“大道至简”的理念,对Go语法特性向来是“不与时俱进”的。自从Go 1.18大刀阔斧的加入了泛型特性后,Go语法特性就又恢复到了之前的“新三年旧三年,缝缝补补又三年”的节奏。Go 1.20亦是如此啊!Release Notes说Go 1.20版本在语言方面包含了四点变化,但看了变化的内容后,我觉得真正的变化只有一个,其他的都是修修补补。

1. 切片到数组的转换

唯一算是真语法变化的特性是支持切片类型到数组类型(或数组类型的指针)的类型转换,这个特性在前瞻一文中系统讲过,这里就不赘述了,放个例子大家直观认知一下就可以了:

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/lang/slice2arr.go

func slice2arrOK() {
    var sl = []int{1, 2, 3, 4, 5, 6, 7}
    var arr = [7]int(sl)
    var parr = (*[7]int)(sl)
    fmt.Println(sl)  // [1 2 3 4 5 6 7]
    fmt.Println(arr) // [1 2 3 4 5 6 7]
    sl[0] = 11
    fmt.Println(arr)  // [1 2 3 4 5 6 7]
    fmt.Println(parr) // &[11 2 3 4 5 6 7]
}

func slice2arrPanic() {
    var sl = []int{1, 2, 3, 4, 5, 6, 7}
    fmt.Println(sl)
    var arr = [8]int(sl) // panic: runtime error: cannot convert slice with length 7 to array or pointer to array with leng  th 8
    fmt.Println(arr)     // &[11 2 3 4 5 6 7]

}

func main() {
    slice2arrOK()
    slice2arrPanic()
}

有两点注意一下就好:

  • 切片转换为数组类型的指针,那么该指针将指向切片的底层数组,就如同上面例子中slice2arrOK的parr变量那样;
  • 转换的数组类型的长度不能大于原切片的长度(注意是长度而不是切片的容量哦),否则在运行时会抛出panic。

2. 其他的修修补补

  • comparable“放宽”了对泛型实参的限制

下面代码在Go 1.20版本之前,比如Go 1.19版本中会无法通过编译:

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/lang/comparable.go

func doSth[T comparable](t T) {
}

func main() {
    n := 2
    var i interface{} = n // 编译错误:interface{} does not implement comparable
    doSth(i)
}

之前,comparable约束下的泛型形参需要支持严格可比较(strictly comparable)的类型作为泛型实参,哪些是严格可比较的类型呢?Go 1.20的语法规范做出了进一步澄清:如果一个类型是可比较的,且不是接口类型或由接口类型组成的类型,那么这个类型就是严格可比较的类型,包括:

- 布尔型、数值类型、字符串类型、指针类型和channel是严格可比较的。
- 如果结构体类型的所有字段的类型都是严格可比较的,那么该结构体类型就是严格可比较的。
- 如果数组元素的类型是严格可比较的,那么该数组类型就是严格可比较的。
- 如果类型形参的类型集合中的所有类型都是严格可比较的,那么该类型形参就是严格可比较的。

我们看到:例外的就是接口类型了。接口类型不是“严格可比较的(strictly comparable)”,但未作为类型形参的接口类型是可比较的(comparable),如果两个接口类型的动态类型相同且值相等,那么这两个接口类型就相等,或两个接口类型的值均为nil,它们也相等,否则不等。

Go 1.19版本及之前,作为非严格比较类型的接口类型是不能作为comparable约束的类型形参的类型实参的,就像上面comparable.go中示例代码那样,但Go 1.20版本开始,这一要求被防控,接口类型被允许作为类型实参赋值给comparable约束的类型形参了!不过这么做之前,你也要明确一点,如果像下面这样两个接口类型底层类型相同且是不可比较的类型(比如切片),那么代码将在运行时抛panic:

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/lang/comparable1.go

func doSth[T comparable](t1, t2 T) {
    if t1 != t2 {
        println("unequal")
        return
    }
    println("equal")
}

func main() {
    n1 := []byte{2}
    n2 := []byte{3}
    var i interface{} = n1
    var j interface{} = n2
    doSth(i, j) // panic: runtime error: comparing uncomparable type []uint8
}

Go 1.20语言规范借此机会还进一步澄清了结构体和数组两种类型比较实现的规范:对于结构体类型,Go会按照结构体字段的声明顺序,逐一字段进行比较,直到遇到第一个不相等的字段为止。如果没有不相等字段,则两个结构体字段相等;对于数组类型,Go会按数组元素的顺序,逐一元素进行比较,直到遇到第一个不相等的元素为止。如果没有不相等的元素,则两个数组相等。

  • unsafe包继续添加“语法糖”

Go 1.17版本在unsafe包增加Slice函数后,Go 1.20版本又增加三个语法糖函数:SliceData、String和StringData:

// $GOROOT/src/unsafe/unsafe.go
func SliceData(slice []ArbitraryType) *ArbitraryType
func String(ptr *byte, len IntegerType) string
func StringData(str string) *byte

值得注意的是由于string的不可更改性,String函数的参数ptr指向的内容以及StringData返回的指针指向的内容在String调用和StringData调用后不允许修改,但实际情况是怎么样的呢?

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/lang/unsafe.go

func main() {
    var arr = [6]byte{'h', 'e', 'l', 'l', 'o', '!'}
    s := unsafe.String(&arr[0], 6)
    fmt.Println(s) // hello!
    arr[0] = 'j'
    fmt.Println(s) // jello!

    b := unsafe.StringData(s)
    *b = 'k'
    fmt.Println(s) // kello!

    s1 := "golang"
    fmt.Println(s1) // golang
    b = unsafe.StringData(s1)
    *b = 'h' // fatal error: fault, unexpected fault address 0x10a67e5
    fmt.Println(s1)
}

我们看到:unsafe.String函数调用后,如果我们修改了传入的指针指向的内容,那么该改动会影响到后续返回的string内容!而StringData返回
的指针所指向的内容一旦被修改,其结果要根据字符串的来源而定了。对于由可修改的底层数组“创建”的字符串(如s),通过StringData返回的指
针可以“修改”字符串的内容;而对于由字符串字面值初始化的字符串变量(如s1),其内容是不可修改的(编译器将字符串底层存储分配在了只读数据区),尝试通过指针修改指向内容,会导致运行时的段错误。

二. 工具链

1. Go安装包“瘦身”

这些年,Go发布版的安装包“体格”是越来越壮了,动辄100多MB的压缩包,以go.dev/dl页面上的go1.xy.linux-amd64.tar.gz为例,我们看看从Go 1.15版本到Go 1.19版本的“体格”变化趋势:

Go 1.15 - 116MB
Go 1.16 - 123MB
Go 1.17 - 129MB
Go 1.18 - 135MB
Go 1.19 - 142MB

如果按此趋势,Go 1.20势必要上到150MB以上。但Go团队找到了“瘦身”方法,那就是:从Go 1.20开始发行版的安装包不再为GOROOT中的软件包提供预编译的.a文件了,这样我们得到的瘦身后的Go 1.20版本的size为95MB!相较于Go 1.19,Go 1.20的安装包“瘦”了三分之一。安装包解压后这种体现更为明显:

➜  /Users/tonybai/.bin/go1.19 git:(master) ✗ $du -sh
495M    .
➜  /Users/tonybai/.bin/go1.20 git:(master) ✗ $du -sh
265M    .

我们看到:Go 1.20占用的磁盘空间仅为Go 1.19版本的一半多一点而已。 并且,Go 1.20版本中,GOROOT下的源码将像其他用户包那样在构建后被缓存到本机cache中。此外,go install也不会为GOROOT下的软件包安装.a文件。

2. 编译器

1) PGO(profile-guided optimization)

Go 1.20编译器的一个最大的变更点是引入了PGO优化技术预览版,这个在前瞻一文中也有对PGO技术的简单介绍。说白了点,PGO技术就是在原有compiler优化技术的基础上,针对程序在生产环境运行中的热点关键路径再进行一轮优化,并且针对热点代码执行路径,编译器会放开一些限制,比如Go决定是否对函数进行内联优化的复杂度上限默认值是80,但对于PGO指示的关键热点路径,即便函数复杂性超过80很多,也可能会被inline优化掉。

之前持续性能剖析工具开发商Polar Signals曾发布一篇文章《Exploring Go’s Profile-Guided Optimizations》,专门探讨了PGO技术可能带来的优化效果,文章中借助了Go项目中自带的测试示例,这里也基于这个示例带大家重现一下。

我们使用的例子在Go 1.20源码/安装包的\$GOROOT/src/cmd/compile/internal/test/testdata/pgo/inline路径下:

$ls -l
total 3156
-rw-r--r-- 1 tonybai tonybai    1698 Jan 31 05:46 inline_hot.go
-rw-r--r-- 1 tonybai tonybai     843 Jan 31 05:46 inline_hot_test.go

我们首先执行一下inline目录下的测试,并生成用于测试的可执行文件以及对应的cpu profile文件供后续PGO优化使用:

$go test -o inline_hot.test -bench=. -cpuprofile inline_hot.pprof
goos: linux
goarch: amd64
pkg: cmd/compile/internal/test/testdata/pgo/inline
cpu: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
BenchmarkA-8        1348        870005 ns/op
PASS
ok      cmd/compile/internal/test/testdata/pgo/inline   1.413s

接下来,我们对比一下不使用PGO和使用PGO优化,Go编译器在内联优化上的区别:

$diff <(go test -run=none -tags='' -timeout=9m0s -gcflags="-m -m" 2>&1 | grep "can inline") <(go test -run=none -tags='' -timeout=9m0s -gcflags="-m -m -pgoprofile inline_hot.pprof" 2>&1 | grep "can inline")
4a5,6
> ./inline_hot.go:53:6: can inline (*BS).NS with cost 106 as: method(*BS) func(uint) (uint, bool) { x := int(i >> lWSize); if x >= len(b.s) { return 0, false }; w := b.s[x]; w = w >> (i & (wSize - 1)); if w != 0 { return i + T(w), true }; x = x + 1; for loop; return 0, false }
> ./inline_hot.go:74:6: can inline A with cost 312 as: func() { s := N(100000); for loop; for loop }

上面diff命令中为Go test命令传入-run=none -tags=”" -gcflags=”-m -m”是为了仅编译源文件,而不执行任何测试。

我们看到,相较于未使用PGO优化的结果,PGO优化后的结果多了两个inline函数,这两个可以被inline的函数,一个的复杂度开销为106,一个是312,都超出了默认的80,但仍然可以被inline。

我们来看看PGO的实际优化效果,我们分为在无PGO优化与有PGO优化下执行100次benchmark,再用benchstat工具对比两次的结果:

$go test -o inline_hot.test -bench=. -cpuprofile inline_hot.pprof -count=100 > without_pgo.txt
$go test -o inline_hot.test -bench=. -gcflags="-pgoprofile inline_hot.pprof" -count=100 > with_pgo.txt

$benchstat without_pgo.txt with_pgo.txt
goos: linux
goarch: amd64
pkg: cmd/compile/internal/test/testdata/pgo/inline
cpu: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
    │ without_pgo.txt │            with_pgo.txt             │
    │     sec/op      │   sec/op     vs base                │
A-8       874.7µ ± 0%   872.6µ ± 0%  -0.24% (p=0.024 n=100)

注:benchstat的安装方法:\$go install golang.org/x/perf/cmd/benchstat@latest

我们看到,在我的机器上(ubuntu 20.04 linux kerenel 5.4.0-132),PGO针对这个测试的优化效果并不明显(仅仅有0.24%的提升),Polar Signals原文中的提升幅度也不大,仅为1.05%。

Go官方Release Notes中提到benchmark提升效果为3%~4%,同时官方也提到了,这个仅仅是PGO初始技术预览版,后续会加强对PGO优化的投入,直至对多数程序产生较为明显的优化效果。个人觉得目前PGO尚处于早期,不建议在生产中使用。

Go官方也增加针对PGO的ref页面,大家重点看看其中的FAQ,你会有更多收获!

2) 构建速度

Go 1.18泛型落地后,Go编译器的编译速度出现了回退(幅度15%),Go 1.19编译速度也没有提升。虽然编译速度回退后依然可以“秒杀”竞争对手,但对于以编译速度快著称的Go来说,这个问题必须修复。Go 1.20做到了这一点,让Go编译器的编译速度重新回归到了Go 1.17的水准!相对Go 1.19提升10%左右。

我使用github.com/reviewdog/reviewdog这个库实测了一下,分别使用go 1.17.1、go 1.18.6、go 1.19.1和Go 1.20对这个module进行go build -a构建(之前将依赖包都下载本地,排除掉go get环节的影响),结果如下:

go 1.20:
$time go build -a github.com/reviewdog/reviewdog/cmd/reviewdog
go build -a github.com/reviewdog/reviewdog/cmd/reviewdog  48.01s user 7.96s system 536% cpu 10.433 total

go 1.19.1:
$time go build -a github.com/reviewdog/reviewdog/cmd/reviewdog
go build -a github.com/reviewdog/reviewdog/cmd/reviewdog  54.40s user 10.20s system 506% cpu 12.757 total

go 1.18.6:
$time go build -a github.com/reviewdog/reviewdog/cmd/reviewdog
go build -a github.com/reviewdog/reviewdog/cmd/reviewdog  53.78s user 9.85s system 545% cpu 11.654 total

go 1.17.1:
$time go build -a github.com/reviewdog/reviewdog/cmd/reviewdog
go build -a github.com/reviewdog/reviewdog/cmd/reviewdog  50.30s user 9.76s system 580% cpu 10.338 total

虽然不能十分精确,但总体上反映出各个版本的编译速度水准以及Go 1.20相对于Go 1.18和Go 1.19版本的提升。我们看到Go 1.20与Go 1.17版本在一个水平线上,甚至要超过Go 1.17(但可能仅限于我这个个例)。

3) 允许在泛型函数/方法中进行类型声明

Go 1.20版本之前下面代码是无法通过Go编译器的编译的:

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/tools/compiler/local_type_decl.go
package main

func F[T1 any]() {
    type x struct{} // 编译错误:type declarations inside generic functions are not currently supported
    type y = x      // 编译错误:type declarations inside generic functions are not currently supported
}

func main() {
    F[int]()
}

Go 1.20改进了语言前端的实现,通过unified IR实现了对在泛型函数/方法中进行类型声明(包括定义type alias)的支持。

同时,Go 1.20在spec中还明确了哪些使用了递归方式声明的类型形参列表是不合法的

type T1[P T1[P]] …                    // 不合法: 形参列表中作为约束的T1引用了自己
type T2[P interface{ T2[int] }] …     // 不合法: 形参列表中作为约束的T2引用了自己
type T3[P interface{ m(T3[int])}] …   // 不合法: 形参列表中作为约束的T3引用了自己

type T4[P T5[P]] …                    // 不合法: 形参列表中,T4引用了T5 并且
type T5[P T4[P]] …                    //          T5引用了T4

type T6[P int] struct{ f *T6[P] }     // 正确: 虽然引用了T6,但这个引用发生在结构体定义中而不是形参列表中

4) 构建自举源码的Go编译器的版本选择

Go从Go 1.5版本开始实现自举,即使用Go实现Go,那么自举后的Go项目是谁来编译的呢?最初对应编译Go 1.5版本的Go编译器版本为Go 1.4。

以前从源码构建Go发行版,当未设置GOROOT_BOOTSTRAP时,编译脚本会默认使用Go 1.4,但如果有更高版本的Go编译器存在,会使用更高版本的编译器。

Go 1.18和Go 1.19会首先寻找是否有go 1.17版本,如果没有再使用go 1.4。

Go 1.20会寻找当前Go 1.17的最后一个版本Go 1.17.13,如果没有,则使用Go 1.4。

将来,Go核心团队计划一年升级一次构建自举源码的Go编译器的版本,例如:Go 1.22版本将使用Go 1.20版本的编译器。

5) cgo

Go命令现在在没有C工具链的系统上会默认禁用了cgo。更具体来说,当CGO_ENABLED环境变量未设置,CC环境变量未设置以及PATH环境变量中没有找到默认的C编译器(通常是clang或gcc)时,CGO_ENABLED会被默认设置为0。

3. 其他工具

1) 支持采集应用执行的代码盖率

在前瞻一文中,我提到过Go 1.20将对代码覆盖率的支持扩展到了应用整体层面,而不再仅仅是unit test。这里使用一个例子来看一下,究竟如何采集应用代码的执行覆盖率。我们以gitlab.com/esr/loccount这个代码统计工具为例,先修改一下Makefile,在go build后面加上-cover选项,然后编译loccount,并对其自身进行代码统计:

// /home/tonybai/go/src/gitlab.com/loccount
$make
$mkdir mycovdata
$GOCOVERDIR=./mycovdata loccount .
all          SLOC=4279    (100.00%) LLOC=1213    in 110 files
Go           SLOC=1724    (40.29%)  LLOC=835     in 3 files
asciidoc     SLOC=752     (17.57%)  LLOC=0       in 5 files
C            SLOC=278     (6.50%)   LLOC=8       in 2 files
Python       SLOC=156     (3.65%)   LLOC=0       in 2 files
... ...

上面执行loccount之前,我们建立了一个mycovdata目录,并设置GOCOVERDIR的值为mycovdata目录的路径。在这样的上下文下,执行loccount后,mycovdata目录下会生成一些覆盖率统计数据文件:

$ls mycovdata
covcounters.4ec45ce64f965e77563ecf011e110d4f.926594.1675678144659536943  covmeta.4ec45ce64f965e77563ecf011e110d4f

怎么查看loccount的执行覆盖率呢?我们使用go tool covdata来查看:

$go tool covdata percent -i=mycovdata
    loccount    coverage: 69.6% of statements

当然, covdata子命令还支持其他一些功能,大家可以自行查看manual挖掘。

2) vet

Go 1.20版本中,go工具链的vet子命令增加了两个十分实用的检测:

  • 对loopclosure这一检测策略进行了增强

具体可参见https://github.com/golang/tools/tree/master/go/analysis/passes/loopclosure代码

  • 增加对2006-02-01的时间格式的检查

注意我们使用time.Format或Parse时,最常使用的是2006-01-02这样的格式,即ISO 8601标准的时间格式,但一些代码中总是出现2006-02-01,十分容易导致错误。这个版本中,go vet将会对此种情况进行检查。

三. 运行时与标准库

1. 运行时(runtime)

Go 1.20运行时的调整并不大,仅对GC的内部数据结构进行了微调,这个调整可以获得最多2%的内存开销下降以及cpu性能提升。

2. 标准库

标准库肯定是变化最多的那部分。前瞻一文中对下面变化也做了详细介绍,这里不赘述了,大家可以翻看那篇文章细读:

  • 支持wrap multiple errors
  • time包新增DateTime、DateOnly和TimeOnly三个layout格式常量
  • 新增arena包
    … …

标准库变化很多,这里不能一一罗列,再补充一些我认为重要的,其他的变化大家可以到Go 1.20 Release Notes去看:

1) arena包

前瞻一文已经对arena包做了简要描述,对于arena包的使用以及最佳适用场合的探索还在进行中。著名持续性能剖析工具pyroscope的官方博客文章《Go 1.20 arenas实践:arena vs. 传统内存管理》对于arena实验特性的使用给出了几点好的建议,比如:

  • 只在关键的代码路径中使用arena,不要到处使用它们
  • 在使用arena之前和之后对你的代码进行profiling,以确保你在能提供最大好处的地方添加arena。
  • 密切关注arena上创建的对象的生命周期。确保你不会把它们泄露给你程序中的其他组件,因为那里的对象可能会超过arena的寿命。
  • 使用defer a.Free()来确保你不会忘记释放内存。
  • 如果你想在arena被释放后使用对象,使用arena.Clone()将其克隆回heap中。

pyroscope的开发人员认为arena是一个强大的工具,也支持标准库中保留arena这个特性,但也建议将arena和reflect、unsafe、cgo等一样纳入“不推荐”使用的包行列。这点我也是赞同的。我也在考虑如何基于arena改进我们产品的协议解析器的性能,有成果后,我也会将实践过程分享出来的。

2) 新增crypto/ecdh包

密码学包(crypto)的主要maintainer Filippo Valsorda从google离职后,成为了一名专职开源项目维护者。这似乎让其更有精力和动力对crypto包进行更好的规划、设计和实现了。crypto/ecdh包就是在他的提议下加入到Go标准库中的

相对于标准库之前存在的crypto/elliptic等包,crypto/ecdh包的API更为高级,Go官方推荐使用ecdh的高级API,这样大家以后可以不必再与低级的密码学函数斗争了。

3) HTTP ResponseController

以前HTTP handler的超时都是http服务器全局指定一个的:包括ReadTimeout和WriteTimeout。但有些时候,如果能在某个请求范围内支持这些超时(以及可能的其他选项)将非常有用。Damien Neil就创建了这个增加ResponseController的提案,下面是一个在HandlerFunc中使用ResponseController的例子:

http.HandleFunc("/foo", func(w http.ResponseWriter, r *http.Request) {
  ctl := http.NewResponseController(w, r)
  ctl.SetWriteDeadline(time.Now().Add(1 * time.Minute)) // 仅为这个请求设置deadline
  fmt.Fprintln(w, "Hello, world.") // 这个写入的timeout为1-minute
})

4) context包增加WithCancelCause函数

context包新增了一个WithCancelCause函数,与WithCancel不同,通过WithCancelCause返回的Context,我们可以得到cancel的原因,比如下面示例:

// https://github.com/bigwhite/experiments/blob/master/go1.20-examples/library/context.go

func main() {
    myError := fmt.Errorf("%s", "myError")
    ctx, cancel := context.WithCancelCause(context.Background())
    cancel(myError)
    fmt.Println(ctx.Err())          // context.Canceled
    fmt.Println(context.Cause(ctx)) // myError
}

我们看到通过context.Cause可以得到Context在cancel时传入的错误原因。

四. 移植性

Go对新cpu体系结构和OS的支持向来是走在前面的。Go 1.20还新增了对freebsd在risc-v上的实验性支持,其环境变量为GOOS=freebsd, GOARCH=riscv64。但Go 1.20也将成为对下面平台提供支持的最后一个Go版本:

  • Windows 7, 8, Server 2008和Server 2012
  • MacOS 10.13 High Sierra和10.14 (我的安装了10.14的mac os又要在go 1.21不被支持了^_^)

近期Go团队又有了新提案:支持WASI(GOOS=wasi GOARCH=wasm),WASI是啥,它是WebAssembly一套与引擎无关(engine-indepent)的、面向非Web系统的WASM API标准,是WebAssembly脱离浏览器的必经之路!一旦生成满足WASI的WASM程序,该程序就可以在任何支持WASI或兼容的runtime上运行。不出意外,该提案将在Go 1.21或Go 1.22版本落地。

本文中的示例代码可以在这里下载。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,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://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 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