标签 goroutine 下的文章

Go并行编程的“第一性原理”:Guy Steele 教你如何“不去想”并行

本文永久链接 – https://tonybai.com/2025/06/29/thinking-parallel-programming

大家好,我是Tony Bai。

在多核处理器已成为标配的今天,并行编程能力几乎是每一位后端工程师的必备技能。Go 语言凭借其简洁的 Goroutine 和 Channel 设计,极大地降低了并发编程的门槛,让我们能相对轻松地驾驭并发。但是,写出“能跑”的并发代码,和写出“优雅、高效、可维护”的并行程序之间,往往还隔着一层思维模式的窗户纸。

今天,我想和大家分享一位计算机科学巨匠——Guy L. Steele Jr.——关于并行编程的深刻洞见。在深入探讨之前,有必要简单介绍一下这位大神:他是 Scheme 语言的共同创造者,Common Lisp 标准的核心定义者,Java 语言设计的关键人物,也是 Sun/Oracle 专门为并行计算设计的 Fortress 语言的领导者。他的见解,源于横跨数十年、从学术到工业的深厚语言设计实践。

他早在多年前(其经典 PPT《How to Think about Parallel Programming—Not!》可以追溯到 2009 年甚至更早)就提出了一些颠覆传统认知,但至今依然闪耀着智慧光芒的核心思想。这些思想,对于我们 Gopher 来说,不啻为并行编程的“第一性原理”,能帮助我们从根本上理解如何更好地设计并行系统。

Steele 的核心论点是什么?一言以蔽之:

“编写并行应用程序的最佳方式,就是不必去考虑并行本身。”

这听起来是不是有点反直觉?别急,让我们慢慢拆解 Steele 的智慧。

并行编程的“敌人”:根深蒂固的“累加器思维”

Steele 犀利地指出,我们过去几十年在顺序编程中养成的许多习惯,正在成为并行编程的障碍。其中,“累加器 (Accumulators)”模式首当其冲被他判为“BAD”

什么是累加器模式?简单来说,就是通过一个共享状态(累加器),不断迭代地用新数据去更新这个状态。一个最经典的例子就是顺序求和:

// 典型的顺序累加求和
func sumSequential(nums []int) int64 {
    var total int64 = 0 // 我就是那个“累加器” total
    for _, n := range nums {
        total += int64(n) // 不断更新自己
    }
    return total
}

这段代码再熟悉不过了,对吧?但在 Steele 看来,这种写法是并行编程的“噩梦”。为什么?

  • 强烈的顺序依赖: 每一步的 total 都依赖于上一步的结果。这种串行依赖使得直接将其并行化变得异常困难。如果多个 Goroutine 同时去更新 total,就需要引入锁或其他同步机制,不仅增加了复杂性,还可能因为锁竞争而严重影响性能,甚至违背了并行的初衷。
  • 鼓励可变状态与副作用: 累加器本身就是一个可变状态,操作带有副作用。这在并行环境下是诸多问题的根源。

Steele 甚至略带调侃地说:DO 循环太上世纪五十年代了!… 当你写下 SUM = 0 并开始累加时,你就已经把自己“坑”了。

那么,我们应该如何摆脱这种“累加器思维”的桎梏呢?

Steele的药方:拥抱“分治”与“结合性”

Steele 提倡的核心思想是 “分治 (Divide-and-Conquer)” 和利用操作的 “代数性质 (Algebraic Properties)”,尤其是 “结合性 (Associativity)”

  1. 分治 (Divide-and-Conquer): 将大问题分解成若干个独立的、可以并行处理的子问题。每个子问题独立求解后,再将结果合并。这天然地契合了并行的思想。

  2. 结合性 (Associativity): 如果一个操作 ⊕ 满足结合律,即 (a ⊕ b) ⊕ c = a ⊕ (b ⊕ c),那么在合并子问题的结果时,合并的顺序就不重要了。这给予了并行执行极大的“自由度”。例如,加法 + 和乘法 * 都满足结合律。

让我们用 Go 来实践一下这种思想,改造上面的求和函数。

Go 实践 1:基于 Goroutine 和 Channel 的分块并行求和

我们可以将数组切分成若干块 (chunk),每个 Goroutine 负责计算一块的和,最后将各块的结果汇总。

import (
    "runtime"
    "sync"
)

func sumParallelChunks(nums []int, numChunks int) int64 {
    if len(nums) == 0 { return 0 }
    if numChunks <= 0 { numChunks = runtime.NumCPU() } // 默认使用CPU核心数作为块数
    if len(nums) < numChunks { numChunks = len(nums) }

    results := make(chan int64, numChunks)
    chunkSize := (len(nums) + numChunks - 1) / numChunks 

    for i := 0; i < numChunks; i++ {
        start := i * chunkSize
        end := (i + 1) * chunkSize
        if end > len(nums) { end = len(nums) }

        // 每个goroutine处理一个独立的块
        go func(chunk []int) {
            var localSum int64 = 0
            for _, n := range chunk { // 块内部仍然是顺序累加,但这是局部行为
                localSum += int64(n)
            }
            results <- localSum // 将局部结果发送到channel
        }(nums[start:end])
    }

    var total int64 = 0
    for i := 0; i < numChunks; i++ {
        total += <-results // 合并结果,加法是结合的!顺序不重要
    }
    return total
}

Go 实践 2:递归分治的并行求和 (更纯粹地体现分治)

对于分治思想,递归往往是更自然的表达:

// 辅助函数,保持接口一致性
func sumRecursiveParallelEntry(nums []int) int64 {
    // 设定一个阈值,小于此阈值则顺序计算,避免过多goroutine开销
    const threshold = 1024
    return sumRecursiveParallel(nums, threshold)
}

func sumRecursiveParallel(nums []int, threshold int) int64 {
    if len(nums) == 0 { return 0 }
    if len(nums) < threshold {
        return sumSequential(nums) // 小任务直接顺序计算
    }

    mid := len(nums) / 2

    var sumLeft int64
    var wg sync.WaitGroup
    wg.Add(1) // 我们需要等待左半部分的计算结果
    go func() {
        defer wg.Done()
        sumLeft = sumRecursiveParallel(nums[:mid], threshold)
    }()

    // 右半部分可以在当前goroutine计算,也可以再开一个goroutine
    sumRight := sumRecursiveParallel(nums[mid:], threshold)

    wg.Wait() // 等待左半部分完成

    return sumLeft + sumRight // 合并,加法是结合的
}

基准测试:并行真的更快吗?

理论归理论,实践是检验真理的唯一标准。我们为上述三个求和函数编写了基准测试,在一个典型的多核开发机上运行(例如,4 核 8 线程的 CPU)。我们使用一个包含 1000 万个整数的切片作为输入。

// benchmark_test.go
package main

import (
    "math/rand"
    "runtime"
    "testing"
    "time"
)

var testNums []int

func init() {
    rand.Seed(time.Now().UnixNano())
    testNums = make([]int, 10000000) // 10 million numbers
    for i := range testNums {
        testNums[i] = rand.Intn(1000)
    }
}

func BenchmarkSumSequential(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumSequential(testNums)
    }
}

func BenchmarkSumParallelChunks(b *testing.B) {
    numChunks := runtime.NumCPU()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        sumParallelChunks(testNums, numChunks)
    }
}

func BenchmarkSumRecursiveParallel(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumRecursiveParallelEntry(testNums)
    }
}

典型的基准测试结果可能如下 (具体数字会因机器而异):

$go test -bench .
goos: darwin
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkSumSequential-8                 429       2784507 ns/op
BenchmarkSumParallelChunks-8             520       1985197 ns/op
BenchmarkSumRecursiveParallel-8          265       4420254 ns/op
PASS
ok      demo    4.612s

从结果可以看出:

  • sumSequential 作为基线,但顺序版本的速度并非最慢。
  • sumParallelChunks 显著快于顺序版本,它充分利用了多核 CPU 的优势,并在这个特定场景下可能因为更直接的控制和较少的递归开销而略胜一筹,但这取决于具体实现和输入规模。而sumRecursiveParallel虽是并行,但却因为较多的goroutine调度(数量大于机器核数)与递归的开销拖慢了执行的速度。

分治与性能:并非总是“更快”的银弹

看到上面的基准测试,你曾经认为的“分治 + 并行”总是能带来性能提升的结论是不成立的。然而,这里需要强调:分治策略本身是为了“能够”并行化,而不是保证在所有情况下都比聪明的顺序算法更快。

这是因为并行化是有成本的:

  1. 任务分解与合并开销: 将问题分解、分发给 Goroutine、以及最后合并结果都需要时间。
  2. Goroutine 创建与调度开销: 虽然 Go 的 Goroutine 很轻量,但创建和调度百万个 Goroutine 仍然有不可忽视的开销。这就是为什么在 sumRecursiveParallel 中我们设置了一个 threshold,当问题规模小于阈值时,退化为顺序执行。
  3. 通信开销: Channel 通信比直接的函数调用要慢。
  4. 同步开销: 如果子问题间不是完全独立,或者合并过程复杂,可能需要额外的同步(如 sync.WaitGroup 或互斥锁),这也会引入开销。

因此,“分治”的性能优势通常在以下情况才能显现:

  • 问题规模足够大: 大到足以摊平并行化的固定开销。
  • 子问题真正独立: 减少或避免同步需求。
  • 合并操作高效: 合并步骤不能成为新的瓶颈。
  • 有足够的并行资源: 即拥有足够的多核 CPU 来同时执行子任务。

如果问题规模很小,或者并行化引入的开销大于节省的时间,那么精心优化的顺序算法可能反而更快。Steele 的核心观点在于,采用分治和关注独立性的设计,使得你的程序具备了“可并行化”的潜力,当资源允许且问题规模合适时,就能获得加速。更重要的是,这种设计往往更清晰、更易于推理和维护。

“独立性”是核心,而非“并行”本身

Steele 强调:“问题的核心并非并行本身,而是独立性。”

如果我们能够将问题分解成独立的部分,并且定义出具有良好代数性质(如结合性)的合并操作,那么并行化就成了一件相对自然和简单的事情。语言和运行时可以更好地帮助我们调度这些独立的任务。

这里,你可能会觉得 Steele 的思想与另一位 Go 圈尽人皆知的思想领袖 Rob Pike 的名言“Concurrency is not Parallelism”有异曲同工之妙。确实如此!

他们都在强调开发者应将关注点从底层执行细节提升到更高层次的程序结构设计上。一个结构良好的程序,自然就具备了高效执行的潜力。

  • Pike 说: 不要去想“并行”(Parallelism)。去想“并发”(Concurrency)——如何把你的程序组织成一组可独立执行、通过通信来协作的组件(Goroutines)。
  • Steele 说: 不要去想“并行”(Parallelism)。去想“独立性”(Independence)——如何把你的问题分解成独立的子问题,并找到一个满足结合律的合并操作。

他们的思想完美互补:

  • Pike 的思想为我们提供了构建程序的“骨架”:我们使用 goroutine 和 channel 来搭建并发结构。
  • Steele 的思想则为我们填充了“血肉”:我们确保每个 goroutine 的工作是真正独立的,并且我们用来合并结果的操作是结合性的

例如,我们的并行求和示例,正是用 Goroutine(Pike 的工具)来执行独立的求和任务(Steele 的独立性原则),然后用 + 这个结合性操作来合并结果。一个优秀的 Gopher,脑中应该同时有这两个声音在对话。

Gopher 的思维重塑:从“怎么做”到“是什么”

Steele 的思想,鼓励我们从更本质的层面思考问题:

  1. 关注“是什么 (What)”而非“怎么做 (How)”: 就像数学家写 Σxᵢ 一样,先声明意图(求和),而不是一开始就陷入具体的循环和累加步骤。Fortran 90 的 SUM(X) 就是这种思想的体现。
  2. 寻找结合性的合并操作: 对于一个问题,思考能否将其分解,并找到一个满足结合律的合并方法。这往往需要对问题域有更深的理解。Steele 在 PPT 中展示了如何通过定义 WordState 及其结合性的 ⊕ 操作来并行化“字符串分词”问题,非常精彩。
  3. 拥抱不可变性与纯函数: 尽可能使子问题的处理函数是纯函数(无副作用,相同输入总有相同输出),这能极大地简化并行程序的推理。
  4. 可复现性至关重要: Steele 强调,为了调试,可复现性极其重要,甚至值得牺牲一些性能。具有结合性的操作通常更容易保证结果的可复现性(即使并行执行顺序不同,最终结果也应一致)。

小结:让并行“自然发生”——Go 做到了吗?

Guy L. Steele Jr. 的思想提醒我们,真正的并行编程高手,不是那些能玩转各种复杂锁和同步原语的“技巧大师”,而是那些能洞察问题本质,将其分解为独立单元,并用优雅的代数方式重新组合的人。他的理想是让并行性像内存管理(垃圾回收)一样,成为语言和运行时为我们处理好的事情,让开发者可以更专注于业务逻辑本身。

那么,Go 语言在“让并行自然发生”这条路上走了多远呢?

  • 显著进步: 相比于 C/C++/Java 等需要手动管理线程、锁、条件变量的语言,Go 通过 go 关键字启动 Goroutine,并通过 Channel 进行通信和同步,极大地简化了并发编程的门槛和心智负担。可以说,Go 让“思考独立性”和“实现基本并发”变得前所未有地容易。

  • 尚未完全“自动化”: 尽管如此,Go 的并行还远未达到像垃圾回收那样“开发者无感知”的程度。开发者仍然需要:

    • 主动设计并行策略: 如何分解问题(如分块、递归分治),如何选择合适的并发原语(Channel, WaitGroup, Mutex)。
    • 管理并发单元: 决定启动多少 Goroutine,如何处理它们的生命周期和错误。
    • 关注数据竞争: 虽然 Channel 有助于避免数据竞争,但如果共享了内存且没有正确同步,数据竞争依然是 Gopher 需要面对的问题(Go 的 race detector 是一个好帮手)。
    • 理解并选择合并策略: 如何设计具有良好代数性质的合并操作,这仍依赖于开发者的洞察力。
  • 与其他语言的比较:

    • Erlang/Elixir (Actor Model): 在进程隔离和消息传递方面与 Go 的 CSP 有相似的哲学,也致力于简化并发。它们在容错和分布式方面有独特优势。
    • 函数式语言 (Haskell, Clojure): 它们强调的不可变性和纯函数天然适合并行化,并提供了一些高级的并行集合与抽象。
    • Rust: 通过其所有权系统和 Send/Sync trait,在编译期提供了强大的内存安全和线程安全保证。其 async/await 提供了另一种并发模型。Rust 在追求极致性能和安全性的同时,其并发的学习曲线也相对陡峭。

Go 的优势在于其务实的平衡: 它提供了足够简单且强大的并发原语,使得开发者能够以较低的成本实现高效的并发和并行,尤其适合构建网络服务和分布式系统。它鼓励开发者思考任务的独立性,但将“如何并行”的许多细节交由开发者根据具体场景来设计。

最终,要达到 Steele 的理想境界——让并行编程像呼吸一样自然,还需要语言、运行时甚至硬件层面的持续进化。但 Go 毫无疑问地在这个方向上迈出了坚实而重要的一大步,它为我们 Gopher 提供了一套强大的工具,去实践“不去想并行(细节),而去思考独立性与组合”的编程智慧。

你对 Guy Steele 的这些观点有什么看法?在你的 Go 并行编程实践中,是否也曾遇到过“累加器思维”带来的困扰,或者通过“分治”获得了更好的解决方案?欢迎在评论区分享你的经验和思考!

参考资料地址 – https://www.infoq.com/presentations/Thinking-Parallel-Programming/


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

Go vs. Rust再掀波澜:Grab真实案例复盘,Gopher如何看待这场“效率与代价”之争?

本文永久链接 – https://tonybai.com/2025/06/24/grab-rewrote-go-service-in-rust

大家好,我是Tony Bai。

最近,东南亚科技巨头、出行公司 Grab 的一篇技术博客《Counter Service: How we rewrote it in Rust》在技术圈引起了不小的震动。他们将一个高 QPS(每秒查询率)的 Go 微服务(Counter Service)用 Rust 进行了重写,结果令人瞩目:在保持相似 P99 延迟性能的前提下,基础设施成本降低了高达 70%!


P99延迟对比:Go(紫色),Rust(蓝色)

这个案例无疑给许多以 Go 作为主力语言的团队和开发者带来了强烈的冲击。Go 语言以其简洁、高效并发、快速编译以及强大的生态系统,在微服务、云原生领域早已占据重要地位。那么,Grab 的这次成功“叛逃”,是否意味着 Go 语言在某些场景下的“护城河”正在被侵蚀?Rust 真的是解决一切性能和成本问题的“银弹”吗?

今天,我们就来深入剖析 Grab 的这个重构案例,看看他们究竟“得”了什么,“失”了什么,以及这背后能给咱们 Gopher 带来哪些宝贵的启示。

Rust 的“杀手锏”:极致效率带来的基础设施成本骤降

Grab 的 Counter Service 主要负责计数和提供 ML 模型/欺诈规则的计数器服务,是一个典型的 I/O 密集型和计算密集型并存的服务,QPS 峰值可达数万。用 Go 实现时,该服务需要大约 20 个 CPU Cores 来支撑。

然而,在用 Rust 重写后,同样的负载下,新的 Rust 服务仅需 4.5 个 CPU Cores!这几乎是 近80% 的资源节省,直接带来了 70%以上的基础设施成本降低。

为什么 Rust 能做到如此极致的效率提升?Grab 的文章和 Rust 语言本身的特性共同揭示了答案:

  • 无垃圾回收 (GC):这是 Rust 相比 Go 在追求极致性能和资源控制上的核心优势。Go 的 GC 虽然已经非常优秀,但在高并发、低延迟场景下,GC 扫描和 STW (Stop-The-World) 仍然可能引入不可预测的延迟抖动和额外的 CPU 开销。Rust 通过所有权系统在编译期保证内存安全,无需运行时 GC,从而消除了这部分开销。
  • 内存安全与零成本抽象:Rust 的所有权、借用检查等机制虽然带来了陡峭的学习曲线,但也确保了内存安全,避免了空指针、数据竞争等常见问题。同时,Rust 的许多高级抽象(如迭代器、闭包)能够在编译期被优化掉,实现“零成本抽象”,性能接近 C/C++。
  • 更精细的控制:Rust 赋予开发者对内存布局、线程模型更细致的控制权,使得在特定场景下可以进行深度优化。

Grab 的案例似乎在证明,当业务场景对资源消耗和运行成本极度敏感,且服务逻辑相对“简单”(Grab 特别强调了选择重写目标时,功能需要足够简单,复杂度可控)时,Rust 的这些特性能够带来实实在在的巨大回报。

光鲜背后的“代价”:Grab 的探索与挑战

然而,享受 Rust 带来的极致效率并非没有代价。Grab 团队在博客中也坦诚地分享了他们遇到的挑战和权衡:

  • 陡峭的学习曲线,尤其是 async

文章提到:对于习惯了 Go 语言简洁 go关键字和 GMP 调度模型的 Gopher 来说,Rust 的所有权、生命周期已经是第一道坎,而 async/await 异步模型及其“函数着色”问题、显式 yield(通过 await)等概念,则带来了更高的认知负荷。Grab 团队也曾因错误地在异步代码中使用了同步 Redis 调用而导致性能不佳。

  • 生态系统与内部库的“阵痛”

虽然 Rust 的生态在快速发展,但在某些特定领域,库的选择可能不如 Go 那样成熟和丰富。Grab 团队在选择 Datadog 和 Redis 客户端库时就进行了一番评估和取舍。

更痛的是内部库的迁移。Grab 内部大量基础库是用 Go 编写的,例如一个使用 Go Templates 进行配置管理的库。在 Rust 项目中,这些 Go 库无法直接复用,团队不得不使用 nom 解析器组合库在 Rust 中重写了类似的功能。这无疑增加了重构的成本和时间。

  • 开发体验的差异

Go 的设计哲学之一就是“简单”,这使得开发者能够快速上手并高效迭代。Goroutine 和 Channel 的易用性,让并发编程的门槛大大降低。相比之下,Rust 为了安全和性能,在语言层面引入了更多复杂性,需要开发者投入更多精力去理解和驾驭。

  • “Rust 一定比 Go 快得多”是迷思

一个非常重要的发现是,Grab 明确指出:“神话 1:Rust 非常快!比 Golang 更快!判定:被驳斥。Golang 对于大多数使用案例来说“足够快”……仅仅为了性能提升而将 Golang 服务重写为 Rust 不太可能带来显著的好处。”

在 P99 延迟方面,Rust 版本与 Go 版本表现相当,甚至有时略差。这告诉我们,Go 在其设计领域内性能已经足够优秀,单纯为了追求“更极致”的速度而用 Rust 重写 Go 服务,可能并不能带来预期的巨大性能提升,反而可能因为生态、开发效率等问题得不偿失。Grab 的主要收益点在于显著的 资源效率 提升。

Gopher 何去何从?几点思考

Grab 的案例无疑是 Go 社区的一面镜子,它照见了 Go 的优势,也揭示了在特定场景下可能存在的“天花板”。作为 Gopher,我们应如何看待这个案例,并从中吸取经验呢?

首先,Go 的核心优势依然稳固。Go 语言以其简洁性、强大的并发模型(Goroutine + Channel)、高效的编译速度、完善的工具链以及成熟的生态系统,继续在云原生、微服务、中间件和 DevOps 工具等领域占据首选或极具竞争力的地位。对于绝大多数业务场景,Go 提供的开发效率和运行性能是“足够好”的,且具有高性价比。

其次,关于何时考虑使用 Rust 进行“动刀”,Grab 的案例提供了几个关键的决策参考点。

  • 在面对极高的 QPS 和资源消耗时,如果服务本身成为性能瓶颈且占用了大量服务器资源,那么迁移可能是合适的。
  • 当功能相对简单且逻辑内聚时,重写的复杂度较低,易于验证,这样可以避免对复杂业务系统进行大规模重写。
  • 当基础设施成本成为显著负担,优化能带来巨大的商业价值时,也应考虑使用 Rust。
  • 团队必须具备掌握 Rust 的能力,成员需熟悉 Rust 并愿意投入时间和资源进行团队赋能。在不满足这些前提条件的情况下,盲目追求 Rust 可能弊大于利。

再者,在考虑语言迁移之前,我们应充分挖掘 Go 本身的优化潜力。例如,进行代码层面的性能分析与优化、架构调整、选择更优的 Go 库,甚至是通过 Go 版本升级带来的 GC 改进等。重写通常应视为最后的手段。

关于 Gopher 是否需要拥抱 Rust,这取决于个人的发展方向和兴趣。如果你专注于业务开发和应用层构建,Go 依然能让你游刃有余。但如果你对系统编程、底层优化、嵌入式或游戏引擎等领域感兴趣,或者所在的公司/团队正在引入 Rust,那么学习 Rust 无疑会为你打开一扇新的大门。即使不深入学习,了解 Rust 的核心理念(如所有权、生命周期和无GC)也能帮助我们更好地理解程序运行的本质,从而写出更健壮、更高效的 Go 代码。

最后,Go 语言的未来同样值得关注。Go 社区在持续进化,例如对泛型的支持提升了表达力,而持续优化的 GC 以及不断丰富的高性能标准库也在不断减少对性能的影响。未来,Go 是否会在某些方面借鉴其他语言的优秀特性,以保持其核心优势的同时,进一步拓展能力边界,值得我们期待。

小结

Grab 用 Rust 重写 Go 服务的案例,再次印证了技术选型中“没有银弹,只有取舍”的黄金法则。Rust 以其极致的性能和资源控制能力,在特定场景下展现了巨大的潜力。但这并不意味着 Go 已经过时或不再优秀。

对于我们 Gopher 而言,重要的是理解不同语言的设计哲学、优势与代价,并根据具体的业务场景、团队能力和长远目标,做出最适合的决策。

你对 Grab 的这个案例有什么看法?你认为在哪些场景下,用 Rust 替代 Go 是值得考虑的?欢迎在评论区留下你的思考!


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

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