async/await 真正的含义并不是“显式切换上下文”，如此说来为何 goroutine 也需要 "go func()" 才能启动并发调度？这难道不是一种类似于 "yield something" 的显式切换上下文吗？

从 Delimited Continuation 的角度说，async/await 是 F#/C# 发明出来用来模仿 Delimited Continuation 的 shift/reset, prompt/control 算子的，这一定程度上解释了函数染色问题从何而来：我们需要显式标记哪些部分能够被编译期改写，这样才能准确地把 k : Continuation 传到这些部分。与之相对的是 Scheme 的 continuation ，任何 continuation 都是无界的，也就是说会捕获到整个 runtime ，这对一个**后续接入** continuation 的语言实现有巨大的 breaking change （在 chez 中执行 `(call/cc (lambda (cc) (cc cc)))`，你会得到 `#<system continuation in new-cafe>`）。

而这样说有一些吊书袋，我们不妨简单思考一下所谓的 coroutine 是怎么编译的？

当我们遇到一个类似于如下的代码

```
let coro = async { time.sleep(5000) }

// some busywork

await coro
```
时，我们单纯从语法考虑，我们如何将 coro 正确编译成我们想要的结构呢？我们自然能想到很多种做法，至少我们可以为 coro 创建一个简单的 reference object ，去轮询来看它是否完成，并把 await 自动重写成 while not coro.ref.isFinished() {} 的一个 busyloop 就可以了（对于有栈来说可以是用户态的 uthread.join()，对于无栈来说可以是 state in [Done, Exception]）。

所以，本质来说，async/await 是定界，界定了到底哪些代码需要被识别成一个 remote track 的对象，并正确插入调度代码。

这个的后续遗留了更多好玩的问题，感兴趣的朋友可以从这些起点思考：
1. 根据前文描述，"go func()" 某种程度也是定界，那跟 async/await 的核心区别是什么？这将为你导向有栈和无栈最核心的区别，究竟“栈”如何让 goroutine 不需要考虑函数染色问题？
2. 如何实现一个可用级别的编译器，编译我们的协程？他们的底层模型其实很相似，但是要搞懂无栈协程的编译难度比较大，你可能需要真的理解 continuation 和 cps conversion 才能明白看似简单的东西背后有多少篇 paper 和大佬支撑。

@ltyj2003 是的，这个应该是主要动机。

在 GF(2) 域上解线性方程组。

是索尼的问题，我是 Xperia 1 V ，偶发会掉，有的时候能一直是 L1 ，有的时候自己莫名其妙就掉 L3 了。最麻烦的地方在于每次都只有在比如开 Netflix 看剧的时候，看分辨率迟迟上不去才会发现，然后打开 DRM check 实锤了再重启，不胜其烦。

先问是不是再问为什么。

FP 跟 “OOP” 本来就是正交的概念，与 FP 相对的是 Imperitive Programming ，而 FP 可以看作一种 Declartive Programming 。在 1994 年确定的 ANSI Common Lisp 标准中，Common Lisp Object System （ CLOS ）已经被完整定义，这是一个完整的对象系统，而被广泛实现的 Meta Object Protocol ，更是后面 Java AOP 的真正前驱。同样，1996 年 OCaml 继承 Caml 衣钵，在 StandardML 基础上发展出了完整的 Object 系统，这也是一个完整的 OOP 系统。而 Scala 跟 Clonjure 这种本身就诞生于 JVM 的语言，更是天生就具有 OOP 能力。

@SimonOne uv 是替代 pip 的，rye 是 flask 作者 mitsuhiko 创始的，他觉得 Python 的研发生态链比起 rust 实在是太烂了，自己搞了一个工具关注整个研发生命周期，使用 独立 python 解释器 + venv + pip + pyproject.toml 等既有生态来管理。后面 astral 团队开发完 uv 之后跟 mitsuhiko 沟通，接管了 rye 项目（ https://astral.sh/blog/uv ）。

从关系上来说，rye 是一个研发管理工具，基于 project 粒度隔离 python 解释器、venv ，自然也就隔离了包管理生态，uv 跟 pip 在 rye 里可以互换，ruff 也不是强制要求接入。

从我个人体感来说，rye + uv + ruff 就是目前最舒服的方案，我有用来实验的 jupyter 项目，也有打包成 oci 的纯 python 项目，rye 都能非常完美去接入和使用（除了某些模型代码里面写死了 pip 之外）。

P.S.，关于 Python 开发者体验和 rye 本身，mitsuhiko 在 rye 创始之初就有个 discussion ，值得一读： https://github.com/astral-sh/rye/discussions/6

@lxdlam 记忆有偏差，最近一年应该

最近两年都在用 rye ，切到 uv 之后体验丝滑

1p 最近一两年一直在做 [developer experience]( https://developer.1password.com/)，现在已经有了 `op` cli, python 和 typescript sdk ，以及两种 prod env 部署模式，对个人来说可以完全替代掉 vault 之类的专业密钥管理系统，就这一点不会让我切换到官方的 password 。

想买的东西大部分都跟这个场景隔开了，本来想买台 mac mini ，但是听说 m4 能做到 apple tv size ，决定等等看；电视 LG C4 跟三星 S90D 合适尺寸的都不参与活动。观望到年底再看看。

一个 off-topic：

Bill Gates 开始他的生涯基本就始于他高中时代跟 Paul 开始的开发合约，其中一个非常知名的就是给他的母校 Lakeside 开发了一个排课系统。根据 Paul 晚年书里所述，他甚至魔改了算法，帮他安排了一节除了他全是女生的英语课。

Ref:
- https://tatler.lakesideschool.org/3085/news/return-to-the-source-lakesides-scheduling-algorithm-explained/
- https://www.businessinsider.com/10-things-you-didnt-know-about-bill-gates-2011-4?op=1&IR=T#he-wrote-his-high-schools-scheduling-program-to-book-him-into-an-english-class-with-all-girls-3

首先是一个时间线：
- 一个 standard 的 iterator 是一个社区一直在讨论跟推进的，正式的 proposal 在 2022 年就已经成型并进行了广泛讨论： https://github.com/golang/go/discussions/54245 。
- rsc 选择了使用 push-func 来实现的讨论，针对于他对*既有* stdlib 的代码的观察 https://github.com/golang/go/discussions/56413 。
- 关于最终加入 spec 的讨论，从 go1.22 到 1.23 release ，数百条关于实现方式、问题、语法选择的讨论都可以在 https://github.com/golang/go/issues/61405 看到。

在这条帖子的讨论中，mix 了非常多的对于不同方向的讨论：
- 该不该加入 Iterator ？这个问题相信毋庸置疑，一个标准化的 iterator 定义能够极大方便用户和库开发者。举个非常简单的例子，我们可以将 `sql.Rows` 传入一个 `slices.Chunk` 函数中，使得只需要
```
for batch := range slices.Chunk(sql.Rows() ,6) {
// do something with current batch
}
````
就能非常简单将 sql 返回的结果分批处理。类似的场景在各种延迟计算、数据获取、基于数据流向的调度中非常常见。
- 该不该使用 push-func 实现？ push-func 跟 pull-func 虽然在表达能力上是一致的，但是 rsc 认为：
> Although push and pull functions are duals, they have important differences. Push functions are easier to write and somewhat more powerful to invoke, because they can store state on the stack and can automatically clean up when the traversal is over. That cleanup is made explicit by the stop callback when converting to the pull form.
push-func 更容易转成 pull-func ，且更容易实现。当然，直观程度上，push-func 是弱于 pull-func 的，这导致了这次语法看起来更加奇怪。（来自于 Java 的例子是，stdlib 对 iterator 的实现是 pull based 的： https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Iterator.html ）
- 该不该使用 rangefunc 实现 iterator ？这个是社区最核心的讨论点之一。援引一个老哥的文章： https://www.gingerbill.org/article/2024/06/17/go-iterator-design/，社区核心始终认为，这种函数破坏了既有用户群体对这个语言的 philosophy （宗旨？方法论？不知道怎么去定义这个词比较好）的认知，一部分群体认为 Go 就是个基于过程的语言，不应该如此“函数式”；同样也有人认为，这种基于完全隐式的控制流（依赖 function stack frame 控制生命周期，range Func 完全依靠 compiler 重写）是引入新的 Bug 的万恶之源。

就我个人来说，我并不赞成使用这种方式实现，如果有一个编译器可以认知的新的 iterator 对象，那无论从实现还是使用角度都会简单很多，而且就 go 整个语言的发展历史来看，为了一些之前没考虑到的事情，动态开洞擦屁股这种事，也不是发生一次两次了。但是这条回复的目的还是给大家一个清晰的认知，也建议讨论设计问题前，先搞清楚前因后果时间脉络，减少鸡同鸭讲。