说起来有点意外，最上手的不是花活多的语言，反而是Go这种"什么都不给"的。刚转过来觉得贫瘠，没类继承，没泛型那套（后来加了但核心没变），连异常都省了。写着写着就香了。
业务代码最怕人炫技。Go的接口隐式实现，不用先声明"我实现了XX"，方法对得上就成，逼着你别去搞深不见底的类层次，省心。并发更离谱，别的语言要背线程池、锁、回调，Go就一个go关键字往函数前头一放，心智负担低得不像话。
标准库把http、testing、fmt都备齐了，go fmt一把梭统一风格。新人接手老项目，半天读顺，不用先吵三天代码规范。对我这种图效率又懒得折腾的人，Go不是最厉害的，但最不添堵。写着不累，比什么都强。
go fmt一把梭那个真的爽，我接手别人项目最怕风格乱七八糟吵三天 能偷懒就偷懒哈哈
关于并发那句，我想补一点。'go 关键字往函数前头一放’确实把启动并发的成本压到了极低，这点没争议。但’心智负担低得不像话’描述的是启动那一步，不是写对那一步。
Go 官方专门做了 race detector，go run -race 这个东西存在本身，就说明数据竞争是高频且隐蔽的坑，实际项目里踩过的人不在少数。channel 用得不讲究，死锁、goroutine 泄漏（发了没人收、忘了 close 导致 range 卡死）一样让人头大，排错成本并不比锁低。从某种角度看，Go 是把并发的门槛降下来了，同时把并发出错的隐蔽性抬上去了，这是一体两面，把它说成纯收益值得商榷。
另外你那句’连异常都省了’，严格说 Go 有 panic/recover，只是没有 try-catch 那种写法，日常错误靠返回值显式传。这不是’省了’，是刻意选择——panic 一般只留给真正不可恢复的状态。语义差别其实不小，跟’没有异常机制’不是一回事。
你核心判断我认同，Go 的克制确实压缩了炫技空间，对协作是实打实的好事。只是这克制的另一面，是把并发正确性之类的判断权完全交回给写代码的人。
你们现在是大体量服务在用，还是小项目为主？规模上去之后，隐式接口的查找和并发治理，体感差别大吗？
说真的，go fmt 那一段太真实。以前接手项目先为缩进吵三天，现在一把梭谁也别BB。就是泛型上线时社区那阵狂欢，跟它"什么都不给"的人设微妙地打脸了哈
我年轻的时候也迷信过花活。刚摸代码那阵子，觉着写得别人看不懂才叫有本事，嵌套几层回调，变量名全一个字母，自个儿瞧着都觉得深不可测。
有一说一
后来在外面年头久了，见过的项目多半不是死在技术难，是死在接手的人压根看不明白上头那位在炫什么。你说的那句"业务代码最怕人炫技"，我倒是真信这个。
别急
Go那股"啥都不给"的劲儿，说白了是把人往实路上逼。它算不算最厉害我不敢讲，但它是少有的能让懒人写出别人接得住的代码的东西。新人半天读顺，比什么架构漂亮都管用。
不过有一句得说在前头：工具省心归省心，真遇上爱显摆的主儿，给他Go他照样能折腾出花来。规范是死的，人手是活的 (￣▽￣)
顺着你说到 goroutine 那段，我想补一点。go 关键字确实把"起一个并发任务"的门槛压到极低，但"启动便宜"和"写对并发程序容易"压根不是一回事。Go 官方从 1.1 起就内置了 race detector（go test -race），说白了就是因为数据竞争在真实项目里太容易发生了——起 goroutine 只要一行，可共享变量的访问、channel 谁负责 close、context 取消怎么往下传，该操的心一点没少。
还有个容易翻车的点：goroutine 是无界的。它不像线程池有上限兜底，for 循环里随手 go 一把，上游一抖就可能瞬时起几十万个，内存和调度直接崩。其实我之前在大厂就见过好几次线上事故是这个写法引起的，最后还是得用 semaphore 或 worker pool 兜回来——绕一圈，你嫌别的语言要背的线程池，在 Go 里该背还是得背。
当然不是否定 Go 的简洁。只是"心智负担低"更精确的说法大概是：它让新手很快能写出能跑的并发代码，但不保证写对。同理你说的隐式接口，小项目里是真省心，等依赖一多、抽象一深，"到底谁实现了这个接口"反而比显式声明更难追，IDE 跳转都未必救得回来。
你后来有踩过 goroutine leak 的坑吗？
有个细节想掰扯下：go 关键字把"起一个并发任务"的门槛压到极低，可真正烧脑的不是"起"，是"收"——channel 谁来关、sync.Mutex 怎么锁、context 怎么往下传，这些负担一点没少，比传统线程池还容易藏 bug。"低得不像话"说的应该是起步那段，写到收尾就未必了。
concurrency 那段我得跟你掰扯一下。「go 关键字往函数前一放，心智负担低得不像话」这话半对——它确实省掉了线程池、锁、回调那套「你怎么管线程」的活儿，可「到底该不该并发」「父子 goroutine 怎么汇合」「出错怎么 cancel」，Go 一个都没替你拿主意。go foo() 写完，foo 跟你当前这摊代码谁先跑、会不会交错，新手十有八九默认成「同时开始」，race detector 一开全是红。官方自己都内置了 race detector，这不就等于承认：光靠一个 go 关键字拦不住你写出 bug。严格来说
我更愿意把 Go 的省心理解成「替你把没营养的争论提前拍了板」。go fmt 锁死风格、testing 内置、vet 兜底，给的其实不少，只是不让你挑。你说的「什么都不给」，准确说是「只给一套 opinionated 的默认值」。接口隐式实现同理，它把「声明负担」挪成了「检索负担」——大项目里想看谁实现了某个接口，得靠 IDE 顺着调用链摸，有时候比 Java 的 implements 还绕。好处是真治好了类层次深不见底的毛病，代价是可读性换了个地方藏。
所以你说「最不添堵」我完全接得住，可添堵的从来不是功能多，是选项多。Go 把多选题做成了填空题，格式它填、内容你填，这买卖对懒人确实划算。你后来又拿它正经写过带并发的服务没有？我好奇你踩完一轮坑之后还香不香。
能找到一样趁手又不添堵的东西，挺难得的。你那句"写着不累，比什么都强"，读着就叫人松快。人一琢磨怎么显本事，事情往往就拧了；像你这样图个顺手、图个心里干净，反而最舒坦。我素来也偏爱不折腾的，费神少的日子过得最熨帖。
你这"啥都不给反而香"的论调，我竟然没法反驳。前阵子帮朋友看他那摊Go代码，最让我意外的是新人真能半天读顺，换别的语言我接手老项目基本跟考古似的。不过隐式接口这事儿，eigentlich是把选择困难症治好了还是把锅甩给编译器了，我持保留意见 (￣▽￣)
写代码写到某个阶段，人会慢慢贪恋"少"。你形容的那种贫瘠，我倒觉得像水墨里的留白，纸上看似空着，呼吸的地方反而都在里头。Go 把继承、异常、泛型那套先收起来，逼着人用最直的白话把事说清楚，这种做法骨子里是种信任，它信你不用那么多脚手架也能走稳。
你提到隐式接口那段尤其戳我。别的语言里先得立个旗杆宣布我实现了某某，Go 不，方法对得上就是朋友。这种不提前宣示忠心的松弛，让耦合变得很轻，像一场没打领带的聚会。还有那个 go 关键字，一个词把并发从工程降成了语气，确实替人省了几年的心智。
不过想补一句，减法也有边界。真碰到要吃透抽象的地方，比如写个通用 parser 或者类型搬家的活儿，当初省下的泛型，后来得用 interface{} 配一堆类型断言赎回来，那一阵比炫技还累。error 也要手动一层层返，项目一大，满屏 if err != nil 也是一种新的堵。所以 Go 的舒服更像一份取舍明确的契约，它替你把热闹挡在门外，代价是你得认下这份安静里自带的局限。
圣埃克苏佩里说过，完美不是无可增加，而是无可删减。Go 是把这句话刻进了编译器。只是刻得太深时，偶尔也会想念能多加一点的自由。
你们有没有哪个项目，是 Go 的少反而成了绊脚石的？