标签 RussCox 下的文章

Go语言的新时代:新领导团队和未来规划

本文永久链接 – https://tonybai.com/2024/10/10/pass-torch-to-go-new-leadership-team

在最近一期的GoTime播客Russ Cox on passing the torch”中,主持人Angelica Hill邀请了Go团队的三个核心角色:前任Tech Leader Russ Cox与现任Tech Leader Austin Clements以及Go运行时和编译器的技术负责人Cherry Mui,一起讨论了Go的领导层交接以及对Go未来的规划。

在播客中,这三人组成的Go的技术领导团队讨论了其内部的重要变动。担任Go技术负责人超过十年的Russ Cox正式卸任,将权杖交给了新的Go技术负责人Austin Clements。同时,Cherry Mui接任Austin之前的职位,成为Go运行时和编译器(也称Go core)的技术负责人。这些领导层变动标志着Go项目发展的一个重要时刻,Austin和Cherry都为各自的角色带来了新的视角,而Russ则转向探索人工智能和软件维护交叉领域的全新角色,继续为团队提供支持。

Russ Cox:回顾12年的领导之路

Russ Cox自2008年起参与Go项目,并于2012年成为其技术负责人。Russ分享了他卸任的想法,对他来说,这一决定是顺其自然的发展。他强调,定期更换领导者至关重要,这有助于引入新思想并防止项目陷入停滞。Russ很早就招募了Austin,因为两人对Go 共享相似的愿景,领导权的交接也进行得十分顺利,Russ仍将继续提供支持。

在他的新角色中,Russ将专注于利用人工智能来简化软件维护工作。他相信,特别是大语言模型,可以帮助自动化诸如问题分类和重复问题检测等耗时的任务。这项探索是一个更广泛的尝试,旨在减少维护人员的工作负担,并提高项目管理的整体效率。

Austin Clements:稳定与增长的愿景

加入Go团队已有十多年的Austin Clements担任新技术负责人,致力于保持Go的稳定性。Austin强调,虽然Go保持着稳定和简洁,但它也必须继续演进。他的首要目标之一是改善Go的可扩展性——无论是在Go的开发过程中,还是在背后的工程流程中。

Austin还希望通过提高透明度和扩大社区参与度,赋能社区。他希望创建能够更好地整合用户反馈的平台(可能是一个Forum),使贡献者能够开发与核心团队目标一致的工具和解决方案。

在性能改进方面,Austin长期致力于优化Go的垃圾回收系统。他目前正在试验一种新算法,幽默地称其为“绿茶”,旨在优化资源使用,进一步推动Go在越来越大的系统上扩展的能力。

Cherry Mui:应对核心扩展性挑战

作为Go运行时和编译器的新技术负责人,Cherry Mui自2016年加入Go团队以来,主要专注于解决与人和机器扩展性相关的问题。Cherry是一个巾帼,为人十分低调,这次GoTime播客第一次贴出了她的照片,根据她的自我介绍,她来自布朗大学化学系,机缘巧合加入了Go团队。从Cherry的声音来看,她是一个“女汉子”,但又与照片的形象不太一致:)。从Cherry的口音来看,她似乎不是土生土长的美国人。

在播客中,Cherry认为,Go的用户基础在快速增长,而核心团队的资源却有限。她的任务是确保Go平台能够支持这一日益增长的社区,无论是通过构建更好的API还是平台,帮助用户在Go的基础上构建更强大的工具和解决方案。

在技术扩展性方面,Cherry也提出了自己的关注点。随着机器变得越来越强大,核心数量和内存容量不断增加,Go需要适应以高效地处理更大的工作负载。Cherry表示,她很期待与社区中的工程师合作,解决这些挑战,保持Go简单且可扩展的声誉。

展望未来:Go的新方向

Austin和Cherry都对各自的新角色和塑造Go未来的机会感到兴奋。尽管他们都不打算对Go语言进行彻底变革,但他们承诺将继续解决Go社区的不断演变需求,并保持其核心理念的稳定性和简洁性。

随着Russ Cox现在专注于人工智能在软件维护中的应用,Austin致力于推动社区参与和技术扩展,Cherry聚焦核心基础设施的改进,Go 项目正进入一个全新的时代。这次过渡不仅仅是领导层的更替,更是一种重新焕发活力的感觉,随着Go团队继续保持其初衷,项目也将在新的领导下迎来新的发展阶段:一个充满技术创新和社区互动的时代。Go社区可以期待在Austin和Cherry带来的新视角引导下,Go项目将会迎来一个更加稳健的发展时期,同时也保持着Russ长期积累的智慧和支持。


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
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

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

为什么Canonical Import Path注释在Go中不再必要

本文永久链接 – https://tonybai.com/2024/10/02/why-canonical-import-paths-no-longer-necessary-in-go

Go语言自推出以来,一直以其简洁和高效的包管理系统著称。在Go 1.11版本之前,Canonical Import Path注释曾是一个重要的工具,用于防止包路径的导入冲突。然而,随着Go Modules的引入,这一工具的作用逐渐被淡化。那么Canonical Import Path注释是否还有必要存在呢?在这篇文章中,我就来介绍一下Canonical Import Path的历史及作用,并通过在Go Modules环境下的向后兼容性测试,讨论是否仍有必要继续使用这一注释。

1. 什么是Canonical Import Path注释?

Go在1.4版本中增加了Canonical Import Path,Canonical Import Path用于解决同一个包可能被通过多个导入路径导入的问题。比如当代码托管在像github.com这样的服务上时,导入路径会包含托管服务的域名,比如“github.com/rsc/pdf。但是Go开发者也可以为同一个包提供一个“自定义”或“vanity”导入路径,例如rsc.io/pdf。这样就会产生两个有效的导入路径,这会带来以下问题:

  • 同一个程序中可能会通过不同路径导入同一个包,造成不必要的重复。
  • 使用非官方路径时可能会错过包更新,因为路径没有得到正确识别。
  • 将包迁移到另一个托管服务时,可能会中断使用旧路径的客户端。

为了解决这个问题,Go 1.4引入了Canonical Import Path注释。在包声明中加上注释后,如果通过非Canonical Import Path导入包,Go命令将拒绝编译导入包的程序。

Canonical Import Path的语法很简单,在包声明的注释部分加上标识。例如,对于rsc.io/pdf包,声明可以写成:

package pdf // import "rsc.io/pdf"

这样,Go命令就会拒绝编译任何通过github.com/rsc/pdf路径导入的包,确保代码可以在不破坏用户代码的前提下自由迁移。

2. Go Modules及其对导入路径的影响

Go 1.11引入Go Modules后,Go通过go.mod文件管理包的依赖关系和版本,极大简化了包的管理过程。通过在go.mod中定义模块的根路径,Go Modules可以自动指示项目中所有包的导入路径,并且是唯一的,这使得Canonical Import Path在Go Modules环境下基本没什么必要性了

例如,假设go.mod文件定义了以下模块路径:

// go.mod
module rsc.io/pdf

那么位于项目根目录下的包的导入路径将被自动解析为rsc.io/pdf,避免了包路径冲突问题。因此,在Go Modules的支持下,手动设置Canonical Import Path注释变得不再必要。

Go提供了Go1向后兼容,在Go module下使用Canonical Import Path注释会是什么情况呢?我们接下来来看看。

3. 在Go Modules下使用Canonical Import Path注释

虽然Go Modules简化了包管理,很多老项目仍然保留了Canonical Import Path注释。为了验证在Go Modules环境下继续使用这些注释的兼容性,我进行了以下测试(测试环境使用的是包括Go 1.23.0版本在内的多个Go版本)。

在这个测试中,我们保持项目中的Canonical Import Path注释不变,看看它是否影响在Go Modules环境中的编译和运行。

这里我们直接使用位于github.com/rsc/pdf中的pdf包,该包在read.go文件中使用了Canonical Import Path注释:

// https://github.com/rsc/pdf/blob/master/read.go
package pdf // import "rsc.io/pdf"

我们先用Go 1.11版本之前的Go版本测试一下导入rsc.io/pdf包。由于Go 1.11版本之前依然采用的是GOPATH构建模式,因此需要先将github.com/rsc/pdf下载到\$GOPATH/src的github.com/rsc下,因为GOPATH模式下,go编译器回到\$GOPATH路径下搜寻依赖包。

接下来,我们建立demo1目录,并直接将github.com/rsc/pdf/pdfpasswd/main.go复制到demo1目录下,该main.go导入了”rsc.io/pdf”,我们将其改为导入”github.com/rsc/pdf”:

// demo1/main.go

package main

import (
    "flag"
    "fmt"
    "log"
    "os"

    "github.com/rsc/pdf"
)

var (
    alphabet  = flag.String("a", "0123456789", "alphabet")
    maxLength = flag.Int("m", 4, "max length")
)

func usage() {
    fmt.Fprintf(os.Stderr, "usage: pdfpasswd [-a alphabet] [-m maxlength] file\n")
    os.Exit(2)
}

func main() {
    log.SetFlags(0)
    log.SetPrefix("pdfpasswd: ")

    flag.Usage = usage
    flag.Parse()
    if flag.NArg() != 1 {
        usage()
    }

    f, err := os.Open(flag.Arg(0))
    if err != nil {
        log.Fatal(err)
    }

    last := ""
    alpha := *alphabet
    ctr := make([]int, *maxLength)
    pw := func() string {
        inc(ctr, len(alpha)+1)
        for !valid(ctr) {
            inc(ctr, len(alpha)+1)
        }
        if done(ctr) {
            return ""
        }
        buf := make([]byte, len(ctr))
        var i int
        for i = 0; i < len(buf); i++ {
            if ctr[i] == 0 {
                break
            }
            buf[i] = alpha[ctr[i]-1]
        }
        last = string(buf[:i])
        println(last)
        return last
    }
    st, err := f.Stat()
    if err != nil {
        log.Fatal(err)
    }
    _, err = pdf.NewReaderEncrypted(f, st.Size(), pw)
    if err != nil {
        if err == pdf.ErrInvalidPassword {
            log.Fatal("password not found")
        }
        log.Fatal("reading pdf: %v", err)
    }
    fmt.Printf("password: %q\n", last)
}

func inc(ctr []int, n int) {
    for i := 0; i < len(ctr); i++ {
        ctr[i]++
        if ctr[i] < n {
            break
        }
        ctr[i] = 0
    }
}

func done(ctr []int) bool {
    for _, x := range ctr {
        if x != 0 {
            return false
        }
    }
    return true
}

func valid(ctr []int) bool {
    i := len(ctr)
    for i > 0 && ctr[i-1] == 0 {
        i--
    }
    for i--; i >= 0; i-- {
        if ctr[i] == 0 {
            return false
        }
    }
    return true
}

然后,我们先用Go 1.10.8版本编译该main.go,得到下面结果:

$go run main.go
main.go:9:2: code in directory /Users/tonybai/Go/src/github.com/rsc/pdf expects import "rsc.io/pdf"

我们看到go 1.11之前的版本对pdf包声明的Canonical Import Path做了检查,如果实际导入路径(github.com/rsc/pdf)与其不符,Go编译器会报错!

接下来,我们来看看切换到go module模式后的编译结果,这里我们使用Go 1.12.7版本。我们创建go.mod文件:

// demo1/go.mod
module demo1

go 1.12

编译执行main.go:

$go run main.go
go: finding github.com/rsc/pdf v0.1.1
go: downloading github.com/rsc/pdf v0.1.1
go: extracting github.com/rsc/pdf v0.1.1
usage: pdfpasswd [-a alphabet] [-m maxlength] file
exit status 2

我们看到,go 1.12.7可以成功编译并运行main.go,即便后者没有使用Canonical Import Path导入pdf包。

而用最新的Go 1.23.0编译和运行,也是没问题的:

$go run main.go
usage: pdfpasswd [-a alphabet] [-m maxlength] file
exit status 2

由此可以得出结论:go module模式下,Go编译器已经不再校验导入包的Canonical Import Path了。

并且,即便main.go同时导入rsc.io/pdf和github.com/rsc/pdf也是没问题的:

import (
    "flag"
    "fmt"
    "log"
    "os"

    "github.com/rsc/pdf"
    _ "rsc.io/pdf"
)

这是因为github.com/rsc/pdf下没有go.mod,go编译器无法识别github.com/rsc/pdf和rsc.io/pdf是同一个包。我们再看一个uber-go/zap的例子:

package main

import (
    "fmt"

    _ "github.com/uber-go/zap"
    _ "go.uber.org/zap"
)

func main() {
    fmt.Println("hello, zap!")
}

针对这个main.go所在的go module进行go mod tidy,我们会得到如下错误结果:

$go mod tidy
go: finding module for package go.uber.org/zap
go: finding module for package github.com/uber-go/zap
go: downloading go.uber.org/zap v1.27.0
go: downloading github.com/uber-go/zap v1.27.0
go: found github.com/uber-go/zap in github.com/uber-go/zap v1.27.0
go: found go.uber.org/zap in go.uber.org/zap v1.27.0
go: demo imports
    github.com/uber-go/zap: github.com/uber-go/zap@v1.27.0: parsing go.mod:
    module declares its path as: go.uber.org/zap
            but was required as: github.com/uber-go/zap

我们看到:go命令检测出了github.com/uber-go/zap仓库下的go module是go.uber.org/zap,我们只能使用go.uber.org/zap作为zap包的导入路径。

4. 是否应移除Canonical Import Path注释?

在Go Modules已经成为Go项目默认包管理方式的背景下,Canonical Import Path的使用显得冗余。虽然保留这些注释不会导致兼容性问题,但移除它们可以让项目代码更加简洁,减少不必要的历史包袱。

对于已经迁移到Go Modules的老项目,开发者可以考虑逐步移除Canonical Import Path注释。对于新项目,则是没有必要添加Canonical Import Path注释,Go Modules已经足够强大,能够管理包路径和依赖;如果项目的用户仍依赖旧版Go工具链(GOPATH模式),保留Canonical Import Path注释则可以作为一种保险措施。

5. 小结

Canonical Import Path注释在Go 1.4引入时是为了解决包路径冲突和包迁移问题。然而,随着Go Modules的引入,包管理和路径控制功能逐渐被自动化,Canonical Import Path的作用显得不再必要。对于现代Go项目,开发者应考虑移除这一冗余的注释,这不仅是代码简化的一部分,也反映了Go生态系统中包管理方式的演进,并使项目更加符合Go语言的现代开发环境。


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
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

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

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