Github | Tony Bai

本文永久链接 – https://tonybai.com/2025/04/10/jetbrains-2024-go-report-analysis

嘿，各位Gopher！

你是否也在关心Go语言的最新动态？它还在快速增长吗？薪资水平如何？未来方向在哪？

这是我看到的关于2024年Go语言发展趋势最全面、数据最翔实的一份报告解读。 JetBrains，这家开发者们都非常熟悉的工具公司，最近发布了《Is Golang Still Growing? Go Language Popularity Trends in 2024》的研究报告文章。如果你是Go开发者，或者正在关注Go生态，这篇文章就是为你准备的，强烈推荐阅读！

在深入细节之前，先为你快速提炼报告的核心发现，让你高效把握重点：

Go开发者规模依旧庞大且专业： 全球专业Go开发者估算超400万，且持续增长。
云原生主战场地位稳固： Web服务、云服务、IT基础设施是Go应用核心领域。
“钱景”诱人： Go开发者薪资普遍处于行业较高水平。
各大榜单表现亮眼： 在TIOBE、GitHub Octoverse等多个权威榜单中，Go排名稳定或显著上升。
与Rust互补而非替代： 两者定位不同，常被结合使用。
未来聚焦： 持续深耕云原生，并在GenAI基础设施领域崭露头角。

Go开发者画像：规模、角色与“钱景”

报告显示，全球使用Go的专业开发者规模可观。JetBrains估计近一年有410万专业人士使用Go，其中180万将其作为主要语言之一。SlashData的估算则更高，达到470万（包含学生和爱好者），而最新的Stack Overflow和SlashData数据推算更是达到了580万。

从上图中展示的开发者从事的软件类型来看：

Web服务 (无GUI): 744,000
网站: 732,000
云服务: 681,000

开发者角色方面(如上图)，除了大量的软件工程师/程序员 (约160万)外，DevOps/基础设施工程师(约50万)的比例也相当高，这凸显了Go在云原生基础设施和运维领域的巨大需求。

更让Gopher们关心的是薪资。报告明确指出，Go开发者是业内薪资最高的人群之一。美国Go开发者的平均年薪约为$76,000，经验丰富者甚至可达$500,000。

Go的应用版图：核心场景与行业分布

Go最常见的两大用例依然是：

API/RPC服务(75%)
命令行工具(62%)

哪些行业在重度使用Go呢？

科技 (超过40%): Google, DataDog, K8s, HashiCorp, Dropbox, Salesforce, Apple…
金融服务 (13%): Monzo, American Express, Mercado Libre…
交通与零售 (10%): Amazon, Uber, DeliveryHero, HelloFresh…
媒体/游戏 (7%): Netflix, Bytedance, Tencent, Reddit, Snap…

多维数据透视：Go在各大榜单上的表现

担心Go的热度？来看看它在各大权威榜单上的表现吧：

JetBrains语言潜力指数: Go排名第4，仅次于TypeScript, Rust, Python，显示出强大的增长潜力和用户粘性。
Stack Overflow开发者调查: 在“受喜爱和期望” (Admired and Desired) 榜单中，Go从去年的第9位跃升至第7位，超过了C#和Shell。
GitHub Octoverse: 稳定保持在 Top 10 编程语言之列，并且是 Top 3增长最快的语言之一 (开源项目活跃度)。
Cloudflare Radar (API客户端语言): Go在2024年 超越Node.js，成为自动化API请求最常用的语言，占比约12% (去年为8.4%)。
TIOBE指数: Go从2023年的第13位大幅攀升至第7位，达到自2009年以来的最高排名！**

TIOBE 2025.04榜单

这些数据有力地证明，Go语言不仅没有衰退，反而在多个维度上保持着强劲的势头。

Go vs Rust：是对手还是队友？

报告特别提到了Go与同样热门的Rust的关系。结论是：它们更多是互补，而非直接竞争。

Go: 更易上手，开发效率高，非常适合云服务、微服务、API、CLI开发，强调 快速开发和可伸缩性。
Rust: 性能极致，适用于性能密集型、底层嵌入式开发，但复杂性更高，开发成本和时间也更高。

许多公司会同时使用这两种语言，根据场景需求选择最合适的工具。对Rust感兴趣的Go开发者增多，并不意味着Go市场份额的下降。

Go的未来之路：聚焦云原生与拥抱GenAI

展望未来，Go团队将继续聚焦云原生领域，满足其对开发效率 (time to value)、可靠性和可伸缩性的核心需求。

一个令人兴奋的新方向是生成式AI (GenAI) 基础设施。虽然Go在传统机器学习领域不如Python，但其在性能和可伸缩性上的优势，使其成为构建AI模型服务 (model serving)等生产级AI基础设施的理想选择。

主流AI平台 (OpenAI, Google AI等) 已提供Go SDK。
Go的GenAI生态正在成长，涌现出如Ollama, LangChain Go, kserve等工具。
GenAI基础设施本身，就像云基础设施一样，正在越来越多地用Go编写。

报告还提到，Go项目领导层虽有变动（Russ Cox卸任，Austin Clements和Cherry Mui接任），但新领导层对Go的理念和目标有深刻理解，确保了项目的连续性和稳定性。Go 1.24已于2025年2月发布，未来可期。

总结：黄金时代，未来可期

总而言之，JetBrains这份详尽的报告描绘了一个清晰的画面：

2024年，Go语言不仅保持了稳定发展，更在云原生领域巩固了核心地位，并在GenAI基础设施等新兴领域展现出强劲潜力。它正步入一个成熟且充满机遇的“黄金时代”。

对于Gopher们来说，持续深耕云原生，关注Go在AI基础设施的应用，无疑是明智的选择。

那么，你认为Go语言的下一个增长点会在哪里？你对Go的未来有什么看法？

欢迎在评论区留下你的真知灼见，一起交流探讨！

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Gopher的AI原生应用开发第一课”、“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用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

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

本文永久链接 – https://tonybai.com/2025/04/03/waitgroup-go-proposal

sync.WaitGroup是Go语言中处理并发任务同步最常用的原语之一。然而，其经典的Add(1)、go func() { defer wg.Done() … }()、Wait()模式虽然强大，却也因其固定写法和潜在的陷阱（如忘记Done或将Add误置于goroutine内部）而让开发者时常感到繁琐，对新手尤其不友好。近日，一项旨在简化这一模式的提案#63796在Go社区引发了广泛关注，并已被标记为Likely Accept，预示着sync.WaitGroup可能很快将迎来一个实用的新方法：Go。这也意味着Go开发者可以告别Add、defer Done的样板代码，并避免它们的“陷阱”可能导致的难以捕捉的代码错误。在这篇文章中，我就来简单介绍一下WaitGroup.Go这个提案。

1. 现有模式的痛点与WaitGroup.Go的提出

当前使用WaitGroup的标准模式通常如下所示：

package main

import (
    "fmt"
    "sync"
    "time"
)

func work(id int) {
    fmt.Printf("Worker %d starting\n", id)
    time.Sleep(time.Second)
    fmt.Printf("Worker %d done\n", id)
}

func main() {
    var wg sync.WaitGroup
    for i := 1; i <= 5; i++ {
        // 注意：在 Go 1.22 之前，需要 i := i 来避免闭包捕获问题
        // i := i
        wg.Add(1) // 必须在启动 goroutine 前调用 Add
        go func(id int) {
            defer wg.Done() // 必须在 goroutine 退出前调用 Done
            work(id)
        }(i)
    }
    wg.Wait() // 等待所有 goroutine 完成
    fmt.Println("All workers done")
}

这种样板使用模式存在几个容器出错的关键点：

wg.Add(1) 的位置: 必须在启动goroutine之前调用。如果将其放在goroutine内部，可能会导致Wait在Add执行前就返回，引发panic或竞态条件。这是最常见的错误之一。
defer wg.Done(): 必须确保在goroutine逻辑结束时调用Done，否则Wait将永久阻塞。defer是推荐做法，但也可能被遗漏。
闭包变量捕获 (Go < 1.22): 在Go 1.22之前的版本中，循环变量直接在goroutine的闭包中使用会导致所有goroutine共享同一个变量值，需要i := i 这样的技巧来创建副本。

为了解决这些问题，提案#63796 建议为sync.WaitGroup添加一个Go方法：

// Go calls f on a new goroutine and adds that task to the WaitGroup.
// When f returns, the task is removed from the WaitGroup.
// ... (其他文档细节省略)
func (wg *WaitGroup) Go(f func()) {
    wg.Add(1)
    go func() {
        defer wg.Done()
        f()
    }()
}

这个方法简洁地封装了Add(1)、启动goroutine和defer Done()的逻辑。使用Go方法后，之前的例子可以大幅简化为下面代码：

package main

import (
    "fmt"
    "sync"
    "time"
)

func work(id int) {
    fmt.Printf("Worker %d starting\n", id)
    time.Sleep(time.Second)
    fmt.Printf("Worker %d done\n", id)
}

func main() {
    var wg sync.WaitGroup // 假设WaitGroup已包含Go方法
    for i := 1; i <= 5; i++ {
        // Go 1.22+版本无需i := i
        wg.Go(func() {
            work(i)
        })
    }
    wg.Wait()
    fmt.Println("All workers done")
}

我们可以看到，代码不仅行数减少，而且显著降低了出错的可能性，尤其是避免了Add位置错误这一高频陷阱。

2. 时机成熟：为何现在是引入WaitGroup.Go的好时机？

该提案并非首次提出（相关讨论可追溯至#18022和#39863），但之前的提案因各种原因未能被接受。此次能够获得”Likely Accept”的状态，可能主要得益于以下几个因素：

Go 1.22循环变量语义变化

Go 1.22正式“修正”了for循环的变量语义，使得每次迭代都会创建新的循环变量实例。这极大地降低了在wg.Go的闭包函数中直接使用循环变量的风险，使得func()形式的API更加安全和自然。正如dsnet在评论中指出的，虽然闭包仍可能引入其他变量修改的风险，但相比wg.Add位置错误，这种风险出现的频率要低得多。

社区实践的验证

许多流行的第三方库（如tailscale.com/syncs和sourcegraph/conc）以及golang.org/x/sync/errgroup都已经实现了类似的Go方法，证明了其在实际开发中的价值和受欢迎程度。这为标准库采纳该模式提供了有力佐证。

错误预防的迫切性

尽管社区曾讨论过通过vet工具检查wg.Add误用（#18022），但此前相关检查迟迟未能落地（直到最近才由adonovan等人推动并合并了相关分析器）。直接在API层面提供更安全的替代方案，被认为是更有效的解决途径。GitHub代码搜索也显示，虽然正确用法占绝大多数，但错误用法（go之后才Add）数量仍然不可忽视（上千例）。

3. 社区讨论焦点

在提案的讨论过程中，社区成员也提出了一些值得思考的问题，这里也找出一些典型的问题供大家玩味：

是否需要新类型？

有人建议创建一个新的类型（如sync.Tasks），以避免WaitGroup同时存在Add/Done和Go两种模式可能带来的混淆。但主流观点认为，将Go方法添加到现有WaitGroup可以方便现有代码的原地升级（gopls甚至已为此添加了自动化重构支持），并且混合使用的风险较低（错误使用Done会快速panic，多余的Add也会导致Wait阻塞，易于发现）。

与errgroup的关系

errgroup.Group也有Go方法，但它还处理了错误传播和context取消。WaitGroup.Go则更纯粹地关注任务同步，两者定位不同，可以共存。将errgroup引入标准库是另一个独立的提案（#57534）。

方法命名

曾有提议使用Start或Run，但Go这个命名与errgroup中的Go保持一致，且能清晰表达“启动新goroutine”的含义，最终获得了更多支持。

文档重塑

Go当前的技术负责人aclements建议将WaitGroup的文档从“计数器”视角转向“任务集合”视角，并将Go作为首选方法进行介绍。对此adonovan提醒WaitGroup本质仍是计数信号量，文档更新需谨慎平衡。

4. 小结

sync.WaitGroup.Go提案的”Likely Accept”状态对于Go开发者来说是一个积极的信号。这个看似简单的补充，有望显著提升Go并发编程的体验，减少Add和Done的样板代码，规避常见错误。它体现了Go团队在保持核心库简洁性的同时，也愿意吸收社区成熟实践、优化开发者体验的务实态度。我们期待在未来的Go版本中看到这一实用特性的正式发布，届时，编写健壮、简洁的并发代码将变得更加容易。