编程与软件工程vorpus.org编辑精选
结构化并发笔记：或者，把 go 语句视为有害
Notes on structured concurrency, or: Go statement considered harmful
2018 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章提出了“结构化并发”的概念，认为 Go 语言的 go 语句像当年的 goto 一样有害：它让并发任务脱离调用者的生命周期，导致取消、错误传播和资源泄漏难以控制。作者提出用“nursery（育婴房）”结构替代裸 go 语句，让并发任务的作用域与代码块绑定，并在 Trio（Python 并发库）中实践了这一设计。
为什么经久不衰：它首次系统阐述了结构化并发思想，影响了 Trio、Kotlin 协程、Swift 等后续语言设计，是理解现代并发 API 演进绕不开的一篇经典。
HN 评论精选
认为作者夸大问题，nursery 只是已有工具的包装，go 与 goto 不可类比
文章提出的 nursery 本质上就是包装过的 sync.WaitGroup / pthread_join / join_all 之类等待所有任务结束的机制，再用类似异常的模型处理错误传播。这是个不错的实用工具，但作者把问题严重夸大、过度吹捧了解决方案。把 go 语句比作 goto 是无视了 goto 的原始问题：goroutine 不会乱跳，它们从主 goroutine 分支出来、遵循正常控制流，语言设计上允许你随手启动而不会出问题。
arghwhat查看英文原文
What. This article proposes a "nursery", which is just a wrapped sync.WaitGroup/pthread_join/futures::future::join_all/a reactor that waits for all tasks to terminate/etc. It then uses an exception-like model for error propagation to "solve" error handling (which is fairly easy to handle with a channel). The construct is a decently usable, already applied tool to handle a set of problems, but the article takes the issue way out of proportions and overhypes the proprosed solution. The "with" example for benefits to not having a "go" statement seem rather bogus, especially seeing that such RAII constructs do not exist in Go (no destructors, remember?). Trying to claim that "go" is as terrible as the original "goto" is ignorance of the original problems. Bad use of goto can be a nightmare to track (as the author tried to illustrate), but goroutines do not jump around, they branch from the main goroutine, following normal control flow from there. They are easy to follow, and the language is designed so that you can throw around with them and forget them without them causing you problems. Also, this article is comparing a list of concurrency constructs and one parallism construct (pthread_create—threading.Thread doesn't count as parallism due to GIL) to callbacks, something which have nothing to do with concurrency at all. Very odd.
认为真正的并发难题是共享数据的控制，而非控制流
这解决错了问题。真正的难题是控制线程间共享的数据，而不是控制流。C/POSIX 线程没有语言层面的机制说明哪些数据被共享、哪个锁保护哪些数据，并发程序的大多数 bug 都源于“谁锁什么”的模糊。Rust 的锁系统把数据和锁绑定在一起，可能是迄今最成功的方案。Go 口头上说“通过通信共享内存”，但语言对控制共享几乎没有支持，Go 程序员已经吃过苦头。Python 受 GIL 限制，这个库也改变不了多核利用的问题。
Animats查看英文原文
This addresses the wrong problem. The real issue is control over data shared between threads, not control flow. C/POSIX type threads have no language support for indicating what data is shared and which locks protect which data. That's a common cause of trouble. The big question in shared memory concurrency is "who locks what". Most of the bugs in concurrent programs come from ambiguities over that question. Early attempts to deal with this at the language level included Modula's "monitors", the "rendezvous" in Ada, and Java "synchronized" classes. These all bound the data and its lock together. Rust's locking system does this, and is probably the most successful one so far. (Yes, the functional crowd has their own approaches.) Go talked a lot about controlling shared memory use. The trouble with goroutines, as Go programmers found out the hard way, was that the "share by communicating, not by sharing" line was bogus. Even the original examples had shared data. But the language didn't provide much support for controlling that sharing. Python is basically at the C level of sharing control over data, except that the Global Interpreter Lock keeps the low-level data structures from breaking. This prevents Python programs from doing much with multi-core CPUs. Since this is just another thread library for Python, it has the same limitations. Real concurrency in Python with disjoint data, and without launching a heavy-weight subprocess, would be a big win. But this isn't it.
实践中 errgroup 已部分解决这些问题，结构化方案对周期性任务也有价值
这也是我通常用 errgroup 而不是裸 go 语句的原因，它解决了取消和错误传播的问题。回想我用裸 go 语句的场景，多半是周期性任务；如果有类似的结构化工具会明显更好，不过影响可能小一些，因为用 go 加 context 写规范的周期性任务没那么痛苦。
lclarkmichalek查看英文原文
This is usually why I end up using https://godoc.org/golang.org/x/sync/errgroup instead of straight go statements, as it addresses some of the cancellation and error propogation issues. When I think of my use of naked go statements, it's usually for periodic tasks; having something similarly structured for them would be a clear win to me (though potentially the impact is less significant, as it's less painful to write a well formed periodic task using the go statement and context).
认为强制结构化并发过于限制，Go 允许按需选择更好
Go 和其他例子有一个关键区别：任何 goroutine 中未捕获的 panic 都会让整个程序崩溃。在多服务单进程架构中，主 goroutine 往往只是启动其他 goroutine，不关心它们是否成功；如果它们是关键的，就应该 panic 崩溃程序。nursery 的限制有它的好处，但我不认为它应该被强制使用。Go 的方式更好：你可以选择用 nursery（errgroup），也可以在不需要管理生命周期时直接用 go，不为不需要的东西付出代价。
orisho查看英文原文
There's one key difference between Go and all the other examples: an uncaught panic in any goroutine, not just the main goroutine, crashes the app. Often your main goroutine will just be starting other goroutines, in a multiple-services-one-process architecture, and it doesn't care whether they succeed or not, and its code need not be aware of whether they're critical. If they are, they should panic and crash the program. Just like a main function that crashes. Doing things with the nursery is restrictive which has its benefits, but I don't agree that it's just strictly always the preferred approach. I prefer an approach like Go's, where you can choose whether to use nurseries (errgroups), and the implementation for them is provided by the language authors. Sure, you are able to start and manage goroutines in this way, even if you don't care about their lifetime - as they are effectively individual programs, but you shouldn't HAVE to. So when you care about goroutines running only while their starter goroutine is at a certain scope, you can do so. But you don't have to, and when you don't need it - you don't need to pay the price. Go appears to take an approach that provides primitives that are as least restrictive as possible to make it easy to read code, but then also has a batteries included approach with its libraries.
历次讨论
同类还值得读
开源应用架构
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编辑精选