这个帖子的目的不是对比不同编程语言开发效率的高低。
这个帖子实际上讨论的是以下内容：
软件工程中生产力消耗的占比
语言层面如何改善生产力的利用率
Go 有何特殊之处
以代码行数来衡量程序员的产出是非常可笑的指标，同理，以代码复杂度、语法糖支持来评价开发效率也很离谱。
如果一定要找一个量化指标来评价开发效率，那就是相同开发需求下所消耗的总人力。
实际上，从理解业务需求开始，到构思实现方式和架构占据了写代码这个过程中绝大部分时间。
如果考虑团队协作的一般场景，沟通成本又占据了团队人力消耗的一半（个人估计）。
也就是说，纯代码层面的效率提升即便优化到极致，对于整个开发成本的改善贡献可能远低于 10%。
能看代码不求人才是最节省沟通成本的方式。
这里的反例就是互联网与工程化兴起之前的各种语言，需要通过外部工具、团队规则才能保证有效协作的各种脚本语言。
开发者讨厌屎山的深层原因还是代码不好读、不好改。
影响可读性的因素很多，这里简单列举几个：
在没有 lsp 辅助的情况下，快速定位到方法的实现，即代码结构组织
隐式控制流，在某些地方隐藏着初始化 init 逻辑，或者有非直接可见的构造、析构方法
人脑的栈空间是非常有限的，间接、隐藏信息越多，理解成本越高。
往小的方面说，直接复制其他代码引入项目算是复用。往大的方面说，包引入机制也是复用。
这里的重点是语言的官方仓库和工具链系统来一致化、规范化这个过程。
缺少官方包管理、没有官方工具链的各种语言都深受其苦。
面向对象的思想就是某个阶段编程语言带来的巨大进步。
在工程化成为现代语言标配的今天，组合替代继承也是巨大进步。
关于这一点我在其他帖子里有零散的论述，这里就不展开了。
我觉得这个部分是误解最多的，大多数的讨论都没有关注到真正的重点。
Go 最重要的贡献之一是基于 chan 的思维模型：Share memory by communication。
日常反复被强调的 goroutine 其实不重要，很多语言也可以有样学样。
通过 chan/goroutine 的结合，初学者即便不理解 race/signal/thread/shared memory 等等概念，一样可以快速、准确地写出并发逻辑。
没有魔法就是编程语言对开发者最大的尊重。
Debug 浪费的生产力往往会远超写代码的节省。
在网络编程的时代，原生 tls 才是真正的跨平台。
技术上跨平台的核心是交叉编译，工程上，保证一条命令构建全平台、全指令集，最后的障碍就是原生 tls 。
这里节省的是构建系统，一旦有了外部依赖，语言自身的工具链就不够用了。
Go 从非常早期就是手搓编译器，而不是转换成 IL 交给通用编译器。缺点是各种语言特性、语法糖都会影响编译器的编写，优点是编译很快。
人类的多线程能力很差，现实任务频繁上下文切换会极大降低工作效率。
如果你曾经被 webpack 构建或者 rust 编译支配，你会理解快速编译、即时反馈的意义。
PS
这个帖子实际价值也就最后一个章节，还没有展开说。权当抛砖引玉，欢迎斧正。特地放到 Go 节点也是不想让话题沦为口水争论。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.