编程与软件工程commandcenter.blogspot.com编辑精选
少即是多：指数级的简化
Less is exponentially more
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Go 语言联合创始人 Rob Pike 2012 年的博文《少即是指数级多》。他解释了 Go 的设计哲学：语言特性越少，反而越能释放程序员的生产力，并反思为什么 C++ 程序员没有如预期般迁移到 Go。这篇文章多年来反复登上 Hacker News 首页，是理解 Go 设计取舍的经典文本。
为什么经久不衰：它记录了 Go 设计哲学的原始表述，而 Go 此后的巨大成功让这篇'宣言'成为检验语言设计简约主义的常读文献。
HN 评论精选
语言设计存在极简美学与工具箱美学两种范式，Go 属于前者
作为职业程序员，我们在工具（语言、编辑器、语言特性）上常被两种对立的审美撕扯：一边是极简主义——像日本书法大师在空房间里，一张纸、一壶墨、一支笔，创造出最完美的艺术，精通意味着剔除一切雕饰；另一边是真实的车间——修车厂、木工房、手术室，摆满工具，精通意味着驯服上千种工具并知道何时用哪一种。编程语言处于这两极之间的连续谱上：Scheme、Go 偏向禅境，Java、C#、Common Lisp、C++ 则是'什么都塞进来'。第一种形象显然更酷，是艺术家和知识分子的审美；第二种是蓝领、技工的形象。
munificent查看英文原文
I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation. On the other side, take a look at your average real workshop: a mechanic's garage, a woodshop, or an operating theatre. They are filled with tools. Mastery is knowing a hundred different implements, each carefully designed for one or a few uses. Mastery means having tamed a thousand tools and knowing which one is the perfect one to apply to the situation at hand. Programming languages live on a continuum between these points. Over in Zen land, you've got Scheme and Go, maybe Smalltalk and JavaScript. Over in everything-but-the-kitchen-sink territory, you've got Java, C#, Common Lisp, and C++. The first image certainly seems cooler: you as code ninja wielding vi and lambdas with deadly precision. It's the aesthetic of the artist and intellectual. The second image is blue collar, the tradesman, the kid who took shop class for four years, the vocational school graduate. If we accept the second image, that says something deep and maybe unpleasant about how we look at our work. But, honestly, I think the reality is that quality professional work often looks like the second picture. Every time I go to Home Depot and get some random tool that only does one thing (basin wrench, water heater element remover, you name it), it takes a job that would be hours of frustration and turns it into child's play, and the quality of the work is better. Simplicity is a virtue worth striving for, but I think it's also valid to want tools perfectly suited for certain tasks. The real art is balancing the two.
Go 缺泛型等设计执念会带来实际痛点，可能阻碍长期采用
Go 有很多优秀特性，我写了几千行代码也很享受，但设计者的一些执念让我觉得它难有前途：1) Rob Pike 以无泛型为傲，导致两年内都没有能容纳任意类型的链表、最小堆、有序映射、B 树等基本数据结构的正经实现，用接口的版本需要别扭的类型转换；2) 不允许简单的 assert 或 EQUALS 宏，测试读起来很痛苦；3) 指针和值的处理方式古怪，容易意外按值拷贝引发 bug；4) channel 在小程序之外用处有限，同步特性使非平凡的并发程序必须小心翼翼避免死锁。人们会忍受这些怪癖一阵子，但最终会离开。
pessimist查看英文原文
Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an ordered map, or a b-tree, or any one of countless data structures that one can take for granted in every other language. And yes, there are implementations that take interfaces, but you have to very odd-looking casts to coerce values in and out of them. 2. Go - or its testing support - doesnt allow a simple assert or EQUALS macro, simply because Rob believes everything should be done with if/then structures. Along with error handling, this makes go tests painful to read. 3. Idiosyncratic handling of pointers and values, leading to confusion everywhere and accidental copies and bugs where people pass by value accidentally because its extremely easy to. 4. Channels aren't really that useful beyond small programs (IMHO, maybe I'm wrong), and by making them synchronous any non-trivial go concurrent program has to reason very carefully to avoid deadlocks. There are countless similar things. People will put up with these idiosyncracies for a while but move on in the end.
Go 吸引的其实是 Python/Java 用户而非 C++ 用户，因为 Pike 高估了 C++ 程序员在并发领域的规模
Rob Pike 困惑于 C++ 程序员为何不愿迁移到 Go，部分原因在于他当时聚焦于特定问题域：那时的 Google 主要写高并发请求处理软件，且几乎全用 C++。在没有 lambda、std::function、std::future 的年代写高并发 C++ 确实痛苦，很多代码呈现出类似 node.js 的回调地狱风格。Go 在写并发程序上全面优于 C++（除非追求极致吞吐或极低延迟），但 Google 之外的人并不用 C++ 写这类程序——他们用 Python、Java，后来是 Node.js。所以毫不奇怪，人们是从这些语言涌向 Go 的，而不是从 C++。
emtel查看英文原文
Rob Pike's confusion about why C++ programmers didn't want to move to go is partially explained by his focus on a particular problem domain at the time Go was being developed. Google in those days was primarily concerned with writing highly concurrent request processing software, and at that time the vast majority of that software was written in C++. Writing highly concurrent C++ in the days before the language had things like lambdas, std::function, std::future, etc was definitely gross. In practice, a lot of the concurrent C++ code from that time period took on the callback-hell flavor of node.js code, but without the concise nature of JS. It was gross. Go is obviously a superior language to C++ for writing concurrent programs in every way except possibly when you need to achieve maximum possible throughput (as in google's search clusters) or minimum possible latency (are HFT shops switching to go? I honestly don't know). However, outside of a few companies that have huge capacity problems, people weren't writing concurrent request serving programs in C++. They were using Python, Java, etc., and later, Node.js. So its no surprise that people flocked to Go from those languages and not C++, because there wasn't a huge population of C++ programmers in this problem domain looking for a better language in the first place. The other C++ programmers were down the hall, working on Chrome and Android (which has a ton of C/C++, despite Java being the primary app development language). The reason they didn't, can't, and won't switch is that managed languages like Go are not well suited to highly resource constrained environments like phones, or browsers that are supposed to run on win XP machines. (To say nothing of games). The advantage of C++ is not, as Pike pompously suggests, that C++ programmers have too much fun playing around with templates and other navel-gazing pursuits. The advantage is that it is a high-level language that lets you do what you need to do with very, very close to the minimum possible resource usage. And there are programming environments where that really matters, and those environments are never going away.
更多特性若能支持更好的抽象，反而更简单；Go 缺泛型正是抽象能力的缺失
一个反例是：当'更多'能带来更好的抽象时，多反而更简单。比如微积分比算术和代数复杂，但它能统一不同的代数表示。我中学学物理时，死记'位移=速度×时间'，却对'位移=初速度×时间+½加速度×时间²'感到困惑；学了导数和积分后，所有公式都通了。在我看来，Go 缺乏抽象能力最体现在没有泛型：你无法用通用方式表达操作，只能复制粘贴，无法准确表达关系——就像我不懂微积分时觉得加速度和位移的关系不透明一样。
RcouF1uZ4gsC查看英文原文
A counterpoint is that more can be simpler when it allows better abstraction. For example, calculus is more complicated that arithmetic and algebra. However, calculus can unify and show relations between different algebraic representations. For example, when I learned physics in middle school, I thought that remembering delta position = velocity * time but struggled with delta position = initial velocity * time + 1/2 (acceleration * time^2) When, I learned about derivatives and integrals, the formulas all made sense. In my opinion Go suffers from the ability to abstract which is most represented in its lack of generics. Instead, of being able to represent operations in a generic way, you are forced to cut and paste, and cannot express the relationship accurately, much as how I considered the relationship between acceleration and position to be opaque before I understood calculus.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选