标签 Glibc 下的文章

Go 1.21新特性前瞻

本文永久链接 – https://tonybai.com/2023/04/26/go-1-21-foresight

Go 1.21版本正在如火如荼地开发当中,按照Go核心团队的一年两次的发布节奏来算,Go 1.21版本预计将在2023年8月发布(Go 1.20版本是在2023年2月份发布的)。

本文将和大家一起看看Go 1.21都会带来哪些新特性。不过由于目前为时尚早,下面列出的有些变化最终不一定能进入到Go 1.21的最终版本中,所以切记一切变更要以最终Go 1.21版本发布时为准。

在细数变化之前,我们先来看看Go语言的当前状态。

1. Go语言当前状态

《2022年Go语言盘点》一文中,我们提到年初Go语言的2022年终排名为12位,同时TIOBE官方编辑也提到:“在新兴编程语言中,Go是唯一一个可能在未来冲入前十的后端编程语言”。Go语言的发展似乎应验了这一预测,在今年的3月份,Go就再次进入编程语言排行榜前十:

一个月后的四月初,TIOBE排行榜上,Go稳住了第10名的位次:

在国内,在鹅厂前不久发布的《2022年腾讯研发大数据报告》中,

在国内,继Go在2021年从C++手中夺过红旗首次登顶鹅厂最热门编程语言之后,在鹅厂前不久发布的《2022年腾讯研发大数据报告》中,Go蝉联鹅厂最热门编程语言,继续夯实在国内头部互联网公司内的优势地位:

Go于2009年开源,在经历多年的宣传和鼓吹后,Go目前进入了平稳发展的阶段。疫情结束后,原先线上举办或取消的国内外的Go技术大会现在陆续又都开始恢复了,相信这会让更多开发人员接触到Go。像Go这样的能在世界各地持续多年举办技术大会的语言真是不多了。

接下来,我们就来聚焦到Go 1.21版本,挖掘一下这个版本都有哪些新特性。

2. 语言变化

目前Go 1.21版本里程碑中涉及语言变化的有大约2项,我们来看看。

2.1 增加clear预定义函数

Go 1.21增加了一个clear预定义函数用来做切片和map的clear操作,其原型如下:

// $GOROOT/src/builtin.go

// The clear built-in function clears maps and slices.
// For maps, clear deletes all entries, resulting in an empty map.
// For slices, clear sets all elements up to the length of the slice
// to the zero value of the respective element type. If the argument
// type is a type parameter, the type parameter's type set must
// contain only map or slice types, and clear performs the operation
// implied by the type argument.
func clear[T ~[]Type | ~map[Type]Type1](t T)

clear是针对map和slice的操作函数,它的语义是什么呢?我们通过一个例子来看一下:

package main

import "fmt"

func main() {
    var sl = []int{1, 2, 3, 4, 5, 6}
    fmt.Printf("before clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))
    clear(sl)
    fmt.Printf("after clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))

    var m = map[string]int{
        "tony": 13,
        "tom":  14,
        "amy":  15,
    }
    fmt.Printf("before clear, m=%v, len(m)=%d\n", m, len(m))
    clear(m)
    fmt.Printf("after clear, m=%v, len(m)=%d\n", m, len(m))
}

运行该程序:

before clear, sl=[1 2 3 4 5 6], len(sl)=6, cap(sl)=6
after clear, sl=[0 0 0 0 0 0], len(sl)=6, cap(sl)=6
before clear, m=map[amy:15 tom:14 tony:13], len(m)=3
after clear, m=map[], len(m)=0

我们看到:

  • 针对slice,clear保持slice的长度和容量,但将所有slice内已存在的元素(len个)都置为元素类型的零值;
  • 针对map,clear则是清空所有map的键值对,clear后,我们将得到一个empty map。

2.2 改变panic(nil)语义

使用defer+recover捕获panic是Go语言唯一处理panic的方法,其典型模式如下:

package main

import "fmt"

func foo() {
    defer func() {
        if err := recover(); err != nil {
            fmt.Printf("panicked: %v\n", err)
            return
        }
        fmt.Println("it's ok")
    }()

    panic("some error")
}

func main() {
    foo()
}

运行上面程序会输出:

panicked: some error

例子中我们向panic传入了表示panic原因的字符串,panic的参数是一个interface{}类型,可以传入任意值,当然也可以传入nil

比如上面例子,当我们给foo函数的panic调用传入nil时,我们将得到下面结果:

it's ok

这可能会给开发者带去疑惑:明明是触发了panic,但函数却按照正常逻辑处理!2018年,前Go核心团队成员bradfitz就提出了一个issue:spec: guarantee non-nil return value from recover,提出当开发者调用panic(nil)时,recover应该返回某种runtime error,而不是nil。这个issue在今年被纳入了Go 1.21版本,现在该issue的实现已经被merge到了主干。

新的实现在src/runtime/panic.go中定义了一个名为PanicNilError的新Error:

// $GOROOT/src/runtime/panic.go

// A PanicNilError happens when code calls panic(nil).
//
// Before Go 1.21, programs that called panic(nil) observed recover returning nil.
// Starting in Go 1.21, programs that call panic(nil) observe recover returning a *PanicNilError.
// Programs can change back to the old behavior by setting GODEBUG=panicnil=1.
type PanicNilError struct {
    // This field makes PanicNilError structurally different from
    // any other struct in this package, and the _ makes it different
    // from any struct in other packages too.
    // This avoids any accidental conversions being possible
    // between this struct and some other struct sharing the same fields,
    // like happened in go.dev/issue/56603.
    _ [0]*PanicNilError
}

func (*PanicNilError) Error() string { return "panic called with nil argument" }
func (*PanicNilError) RuntimeError() {}

Go编译器会将panic(nil)替换为panic(new(runtime.PanicNilError)),这样我们用Go 1.21版本运行上面的程序,我们就会得到下面结果了:

panicked: panic called with nil argument

如果你的遗留代码中调用了panic(nil)(注:显然这不是一种很idiomatic的作法),升级到Go 1.21版本后你就要小心了。如果你想保留原先的panic(nil)行为,可以用GODEBUG=panicnil=1。

有童鞋可能会质疑这违反了Go1兼容性承诺,但实际上Go1兼容性规范保留了对语言规范中不一致或错误的修订权力,即便这种修订会导致遗留代码出现与原先不一致的行为。

3. 编译器与工具链

每个Go版本中,编译器和工具链的改动都不少,我们挑重点看一下:

3.1 一些OS的最小支持版本的更新

Go 1.21开始,go installer支持最小macOS版本更新为10.15,而最小Windows版本为Windows 10

3.2 低版本的go编译器将拒绝编译高版本的go module

从Go 1.21版本开始,低版本的go编译器将拒绝编译高版本的go module(go.mod中go version标识最低版本) ,这也是Russ Cox策划的Go扩展的向前兼容性提案的一部分。此外,Go扩展向前兼容性提案感觉比较复杂,可能不会全部在Go 1.21版本落地。

3.3 支持WASI

Go从1.11版本就开始支持将Go源码编译为wasm二进制文件,并在支持wasm的浏览器环境中运行。

不过WebAssembly绝不仅仅被设计为仅限于在Web浏览器中运行,核心的WebAssembly语言是独立于其周围环境的,WebAssembly完全可以通过API与外部世界互动。在Web上,它自然使用浏览器提供的现有Web API。然而,在浏览器之外,之前还没有一套标准的API可以让WebAssembly程序使用。这使得创建真正可移植的非Web WebAssembly程序变得困难。WebAssembly System Interface(WASI)是一个填补这一空白的倡议,它有一套干净的API,可以由多个引擎在多个平台上实现,并且不依赖于浏览器的功能(尽管它们仍然可以在浏览器中运行)。

Go 1.21将增加对WASI的支持,初期先支持WASI Preview1版本,之后会支持WASI Preview2版本,直至最终WASI API版本发布!目前我们可以使用GOOS=wasip1 GOARCH=wasm将Go源码编译为支持WASI的wasm程序,下面是一个例子:

// main.go
package main            

func main() {
    println("hello")
}

下载最新go dev版本后(go install http://golang.org/dl/gotip@latest),可以执行下面命令将main.go编译为wasm程序:

$ GOARCH=wasm GOOS=wasip1 gotip build -o main.wasm main.go

开源的wasm运行时有很多,wazero是目前比较火的且使用纯Go实现的wasm运行时程序,安装wazero后,可以用来执行上面编译出来的main.wasm:

$curl https://wazero.io/install.sh
$wazero run main.wasm
hello

3.4 Go 1.21可能推出纯静态工具链,不再依赖glibc

使用纯Go实现的net resolver,原先DNS的问题也将被解决,这样Go团队很可能在构建工具链的时候使用CGO_ENABLED=0构建出静态工具链,没有动态链接库的依赖。

3.5 go test -c支持为多个包同时构建测试二进制程序

Go 1.21版本之前,go test -c仅支持将单个包的测试代码编译为测试二进制程序,Go 1.21版本则允许我们同时为多个包构建测试二进制程序

下面是官方给出的例子:

$ go test -c -o /tmp ./pkg1 ./pkg2 ./pkg2
$ ls /tmp
pkg1.test pkg2.test pkg3.test

3.6 增加\$GOROOT/go.env

今天使用go env -w命令修改的默认环境变量会写入:filepath.Join(os.UserConfigDir(), “go/env”)。在Mac上,这个路径是\$HOME/Library/Application Support/go/env;在Linux上,这个路径是\$HOME/.config/go/env。

Go 1.21将增加一个全局层次上的go.env,放在\$GOROOT下面,目前默认的go.env为:

// $GOROOT/go.env

# This file contains the initial defaults for go command configuration.
# Values set by 'go env -w' and written to the user's go/env file override these.
# The environment overrides everything else.

# Use the Go module mirror and checksum database by default.
# See https://proxy.golang.org for details.
GOPROXY=https://proxy.golang.org,direct
GOSUMDB=sum.golang.org

我们仍然可以通过go env -w命令修改user级的env文件来覆盖上述配置,当然最高优先级的是OS用户环境变量,如果在OS用户环境变量文件(比如.bash_profile、.bashrc)中设置了Go的环境变量值,比如GOPROXY等,那么以OS用户环境变量为优先。

4. 标准库

我们接下来再来看看变更最多的一部分:标准库,我们将对主要变更项作简要介绍。

4.1 slices和maps进入标准库

Go 1.18版本泛型落地发布前的最后一刻,Rob Pike叫停了slices、maps等泛型包的入库,后来这两个包先放置在golang.org/x/exp下作为实验包。随着Go泛型日益成熟以及Go团队对泛型使用经验的增多,Go团队终于决定将golang.org/x/exp/slicesgolang.org/x/exp/maps在Go 1.21版本中将挪入标准库。

4.2 log/slog加入标准库

log/slog是Go官方版结构化日志包,大致与uber的zap包相当。在我之前的一篇文章《slog:Go官方版结构化日志包》有对slog的详尽说明,大家可以移步到那篇文章看看。不过slog的proposal依旧很多,后续slog可能会有持续改进和变更,与那篇文章中的内容可能会有一些差异。

4.3 sync包增加OnceFunc、OnceValue和OnceValues

在sync.Once的基础上,这个issue增加了三个与Once相关的”语法糖”API,用在一些对Once有需求的最常见的场景中。

4.4 增加testing.Testing函数

Go 1.21为testing包增加了func Testing() bool函数,该函数可以用来报告当前程序是否是go test创建的测试程序。使用Testing函数,我们可以确保一些无需在单测阶段执行的函数不被执行。比如下面例子来自这个issue:

// file/that/should/not/be/used/from/testing.go

func prodEnvironmentData() *Environment {
    if testing.Testing() {
        log.Fatal("Using production data in unit tests")
    }
    ....
}

4.5 一些变更点

5. 参考资料


“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

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

后端程序员一定要看的语言大比拼:Java vs. Go vs. Rust

这是JavaGo和Rust之间的比较。这不是基准测试,更多是对可执行文件大小、内存使用率、CPU使用率、运行时要求等的比较,当然还有一个小的基准测试,可以看到每秒处理的请求数量,我将尝试对这些数字进行有意义的解读。

为了尝试尽可能公平比较,我在此比较中使用每种语言编写了一个Web服务。Web服务非常简单,它提供了三个REST服务端点(endpoint)。


Web服务提供的服务端点

这三个Web服务的代码仓库托管在github上

编译后的二进制文件尺寸

有关如何构建二进制文件的一些信息。对于Java,我使用maven-shade-pluginmvn package命令将所有内容构建到一个大的jar中。对于Go,我使用go build。最后,我使用了cargo build –release构建Rust服务的二进制文件。


每个程序的大小(以兆字节为单位)

编译后的文件大小还取决于所选的库/依赖项,因此,如果依赖项的身躯臃肿,则编译后的程序也将难以幸免。在我的特定情况下,针对我选择的特定库,以上是程序编译后的大小。

在后续的一个单独小节中,我会把这三个程序都构建并打包为docker镜像,并列出它们的大小,以显示每种语言所需的运行时开销。下面有更多详细信息。

内存使用情况

空闲状态


每个应用程序在内存空闲时的内存使用情况

什么?Go和Rust版本显示空闲时内存占用量的条形图在哪里?好了,它们在那里,只有JVM启动的程序在空闲状态时消耗160 MB以上的内存,它什么也没做。Go应用程序仅使用0.86 MB,Rust应用也仅使用了0.36 MB。这是一个巨大的差异!在这里,Java使用的内存比Go和Rust应用使用的内存高出两个数量级,只是空占着内存却什么都不做。那是巨大的资源浪费。

服务REST请求

让我们使用wrk发起访问API的请求,并观察内存和CPU使用情况,以及在我的计算机上三个版本程序的每个端点每秒处理的请求数。

wrk -t2 -c400 -d30s http://127.0.0.1:8080/hello
wrk -t2 -c400 -d30s http://127.0.0.1:8080/greeting/Jane
wrk -t2 -c400 -d30s http://127.0.0.1:8080/fibonacci/35

上面的wrk命令使用两个线程并在连接池中保持400个打开的连接,并重复调用GET端点,持续30秒。这里我仅使用两个线程,因为wrk和被测程序都在同一台计算机上运行,所以我不希望它们在可用资源(尤其是CPU)上相互竞争(太多)。

每个Web服务都经过单独测试,并且在每次运行之间都重新启动了Web服务。

以下是该程序的每个版本的三个运行中的最佳结果。

  • /hello

该端点返回Hello,World!信息。它分配字符串“ Hello,World!” 并将其序列化并以JSON格式返回。


/hello端点的CPU使用率


/hello端点的内存使用情况


/hello端点处理的每秒请求数

  • /greeting/{name}

该端点接受一个段路径参数{name},然后格式化字符串“Hello,{name}!”,序列化并以JSON格式的问候消息返回。


/greeting端点的CPU使用率


/greeting端点的内存使用情况


/greeting端点处理的每秒请求数

  • /fibonacci/{number}

该端点接受一个段路径参数{number},并返回序列化为JSON格式的斐波纳契数和输入数。

对于这个特定的端点,我选择以递归形式实现它。我毫不怀疑,迭代实现会产生更好的性能结果,并且出于生产目的,应该选择一种迭代形式,但是在生产代码中,有些情况下必须使用递归(并非专门用于计算第n个斐波那契数 )。为此,我希望该实现涉及大量CPU栈分配。


/fibonacci端点的CPU使用率


/fibonacci端点的内存使用情况


/fibonacci端点处理的每秒请求数

在Fibonacci端点测试期间,Java是唯一一个有150个请求超时的实现,如下面wrk的输出所示。


超时时间


/fibonacci端点的延迟

运行时大小

为了模拟现实世界中的云原生应用程序,并避免“它仅可以在我的机器上运行!”,我分别为这三个应用程序创建了一个docker镜像。

Docker文件的源代码包含在代码库相应程序文件夹下。

作为我使用过的Java应用程序的基础镜像,openjdk:8-jre-alpine是已知大小最小的镜像之一,但是,这附带了一些警告,这些警告可能适用于您的应用程序,也可能不适用于您的应用程序,主要是alpine镜像在处理环境变量名称方面不是posix兼容的,因此您不能在Dockerfile中使用ENV中的(点)字符(不过这没什么大不了的),另一个是alpine Linux镜像是使用musl libc而不是glibc编译的,这意味着如果您的应用程序依赖于需要glibc,它可能无法正常工作。不过,在这里,alpine镜像工作是正常的。

至于应用程序的Go版本和Rust版本,我已经对其进行了静态编译,这意味着它们不希望在运行时镜像中存在libc(glibc,musl…等),这也意味着它们不需要运行OS的基本镜像。因此,我使用了scratch docker镜像,这是一个no-op镜像,以零开销托管已编译的可执行文件。

我使用的Docker镜像的命名约定为{lang}/webservice。该应用程序的Java,Go和Rust版本的镜像大小分别为113、8.68和4.24 MB。


最终Docker镜像大小

结论


三种语言的比较

在得出任何结论之前,我想指出这三种语言之间的关系。Java和Go都是支持垃圾回收的语言,但是Java会提前编译为在JVM上运行的字节码。启动Java应用程序时,JIT编译器会被调用以通过将字节码编译为本地代码来优化字节码,以提高应用程序的性能。

Go和Rust都提前编译为本地代码,并且在运行时不会进行进一步的优化。

Java和Go都是支持垃圾收集的语言,具有STW(停止世界)的副作用。这意味着,每当垃圾收集器运行时,它将停止应用程序,进行垃圾收集,并在完成后从停止的地方恢复应用程序。大多数垃圾收集器需要停止运行,但是有些实现似乎不需要这样做。

当Java语言在90年代创建时,其最大的卖点之一是一次编写,可在任何地方运行。当时这非常好,因为市场上没有很多虚拟化解决方案。如今,大多数CPU支持虚拟化,这种虚拟化抵消了使用某种语言进行开发的诱惑(该语言承诺可以运行在任何平台上)。Docker和其他解决方案以更为低廉的代价提供虚拟化。

在整个测试中,应用程序的Java版本比Go或Rust对应版本消耗了更多的内存,在前两个测试中,Java使用的内存大约增加了8000%。这意味着对于实际应用程序,Java应用程序的运行成本会更高。

对于前两个测试,Go应用程序使用的CPU比Java少20%,同时处理比java版多出38%的请求。另一方面,Rust版本使用的CPU比Go减少了57%,而处理的请求却增加了13%。

第三次测试在设计上是占用大量CPU的资源,因此我想从中挤出CPU的每一分。Go和Rust都比Java多使用了1%的CPU。而且我认为,如果wrk不是在同一台计算机上运行,那么这三个版本都会使CPU达到100%的上限值。在内存方面,Java使用的内存比Go和Rust多2000%。Java可以处理的请求比Go多出20%,而Rust可以处理的请求比Java多出15%。

在撰写本文时,Java编程语言已经存在了将近30年,这使得在市场上寻找Java开发人员变得相对容易。另一方面,Go和Rust都是相对较新的语言,因此与Java相比,自然而然的开发人员的数量更少些。不过,Go和Rust都拥有很大的吸引力,许多开发人员正在将它们用于新项目,并且有许多使用Go和Rust的生产中正在运行的项目,因为简单地说,就资源而言,它们比Java更有效。

在编写本文的程序时,我同时学习了Go和Rust。就我而言,Go的学习曲线很短,因为它是一种相对容易掌握的语言,并且与其他语言相比语法很小。我只用了几天就用Go编写了程序。关于Go需要注意的一件事是编译速度,我不得不承认,与Java/C/C++/Rust等其他语言相比,它的速度非常快。该程序的Rust版本花了我大约一个星期的时间来完成,我不得不说,大部分时间都花在弄清borrow checker向我要什么上。Rust具有严格的所有权规则,但是一旦掌握了Rust的所有权和借用概念,编译器错误消息就会突然变得更加有意义。违反借阅检查规则时,Rust编译器对您大吼的原因是因为编译器希望在编译时证明已分配内存的寿命和所有权。这样做可以保证程序的安全性(例如:没有悬挂的指针,除非使用了不安全(unsafe)的代码逃离检查),并且在编译时确定了释放位置,从而消除了垃圾收集器的需求和运行时成本。当然,这是以学习Rust的所有权系统为代价的。

在竞争方面,我认为Go是Java(通常是JVM语言)的直接竞争对手,但不是Rust的竞争对手。另一方面,Rust是Java,Go,C和C ++的重要竞争对手。

由于他们的效率,我看到了自己将会在Go和Rust中编写更多的程序,但是很可能在Rust中编写更多的程序。两者都非常适合Web服务,CLI,系统程序(..etc)开发。但是,Rust比Go具有根本优势。它不是垃圾收集的语言,与C和C++相比,它可以安全地编写代码。例如,Go并不是特别适合用于编写OS内核,而这里又是Rust的亮点,并与C/C ++竞争,因为它们是使用OS编写的长期存在和事实上的语言。Rust与C/C++竞争的另一种方式在嵌入式世界中,我将继续进行讨论。

感谢您的阅读!

本文翻译自《Comparison between Java, Go, and Rust》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商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
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系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