@lxdlam typo：这种双类型语言 => 这种支持双类型（甚至更多类型）组成异构容器的语言

单从两种范式上来说，值类型跟异常类型错误直接比较很难比较清楚：

- 值类型还是将错误当作值，本身没有控制流操作，所以当作值处理可以轻松当作比如 data 的一部分到处传递处理等等，缺点就是缺乏强制力，简单把值 ignore 掉就可以丢掉错误，而大家都倾向于懒一点；
- 异常类型可以打断并接管控制流，更加强大，guarantee 也更好，如果 runtime 实现得不错（比如 Java ）那用起来其实还是很舒服的，缺点就是这个特性很容易被误用（相信大家都听说过或者见过用 exception 传值的业务代码）。

两种范式各有优劣，其实没有直接关系，语言风格而已。

而单纯讨论值类型错误，Go 的实现有自己的优势。错误这个东西本身就是很容易产生很多 concrete type 的，基于 duck typing 的 interface 化，其实大大简化很多操作，比如直接把已有 error wrap 起来，然后实现一下 `Error` 和一些 helper function ，就能快速搞一个新的错误出来，开发效率是很高的（没有 thiserror 和 anyhow 之前，Rust 搞个自定义错误有多痛苦，相信很多朋友深有体会）。
Go 最大的问题其实在于，他采用了值类型错误，但是类型系统支持非常 basic ，导致大家处理错误非常痛苦。比如在类型系统比较现代的语言中，这种双类型语言或多或少能实现一定程度的 monad ，这样我们就可以写出类似于：
```
let val = some_function().map(fun).map(foo).map(bar);

match val {
Ok(v) => println!("Value is: {}", v),
Error(e) => println!("Failed! error: {}", e),
}
```
在这里面，我们我们确实不关心中间错误，直接 chain 起来，处理最后错误就行，而如果我们关心比如到某一步的错误，我们单独接一下这一步的结果就可以拿到中间结果再做处理。无论是看起来还是读起来，其实都非常清晰明了。而可惜的是，Go 因为一开始设计压根没想这个问题，导致现在的打补丁的 generics ，很长线看起来都很难支持这种比较完备的 monad 特性。所以，我们只能一步步 if-else ，或者将这三个函数塞到一个 slice 里面，用 `reflect` 循环每个函数 apply 去每一步拿一下 type 信息做一些非常丑的补丁。
稍微补一句：为啥这里需要比较好的类型系统才能实现？在上面的流程中，实际上 `map` 接到的函数签名类型是各不一样的，有比较好类型系统的编译器在这里可以做非常好的静态推断；或者我们完全交给动态类型，损失一定 runtime 性能也能做到。而可惜的是，Go 既要选择尽量静态类型，又没把静态类型做很好，就卡在这了。

一个角度，其实是优胜劣汰：只有以前稳定、优秀的软件才能在现在才会被多次提及，一种幸存者偏差。

巴别塔圣歌。

作者对语言系统有一定理解，对语言、文化氛围的塑造有出色的把控能力，唯一缺点就是结尾略显机械降神，缺点意思。

@northbrunv 会一个即可，如果会 Vue 更好。

单纯只看的话确实 Sumatra PDF 最好用，也是 Windows 平台上个人体验 LaTeX 预览配合最好的 previewer

- 宏：基本上来说宏就是把编译器当做自己的预处理器来做 codegen ，从提案和实现上来看，Swift 的实现还是比较累赘，简化宏的构建和未来使用上，应该还有些工作可以做。
- 跟 C++ interop：本身也是把脏活累活交给 LLVM ，编译器多做一步 parsing ，然后做 codegen ，生成另一边的 binding ，重点看易用性，这一块做的比较好的是 Julia ，不仅可以直接 call C/C++（需要用 Cxx.jl 包）函数，更可以直接在 Julia 里面写对应代码，下面直接调用。Swift 的易用性目前看起来还是不错，期待明天的演讲。至于 CMake 编译工具的整合，是一个很 intuitive 的结果，Swift 支持编译器插件之后，这种加 custom pass 的工作就变得很简单了，比如 zig 也支持直接混合编译 C/C++/zig 代码库。

苹果这次硬件跟技术还都挺成熟的。
- 技术：Vision Framework 做人体识别+骨骼绑定，ARKit 6 和 Reality Kit 都已经在去年 WWDC 布局好了，R1 芯片专门一个 rendering 和传感器的 RTOS subsystem 处理，M2 带来的够用的算力等等，可以认为他发布的东西基本都是真实的；
- 硬件：专门定制的双 4K 镜片，眼动+虹膜识别摄像头，其他的一些环境捕获的摄像头现有的 VR 方案也都基本搞过了。

从产品角度上来说，Vision Pro 的价格和配置算是合理的，电池这种本身就是被物理极限限制住的东西，在相应的新材料取得突破之前，也算是可以接受。

但是苹果始终没解决最核心的问题：内容产出和供应门槛问题。
- 发布会上苹果给出的解决方案还是自己的 3D scene 构建工具 Reality Composer 以及跟 Unity 合作，这些都是业界现有的链路，仍然是学习门槛比较高：假定只比较凑合能看，视频跟音频领域现在要做一个凑合能看的产物难度很低，但是 3D 领域还是需要基础知识+软件操作的复杂学习；苹果自己也没想好这个东西的 killer app 是啥，现在这个头显能做的事情，其他头显不管做得好还是不好，但是看上去都能做，而且价格远低于苹果的方案。这部分没有解决的话，生态是后继乏力的。
- 另一个问题就是价格，根据现在的价格，开发者更可能选择开发一个 ios 应用并将其发布到 Vision Pro App Store ，而不是专门做 Vision Pro 的 killer app ，因为价格的问题导致市场较小，ROI 其实并不高。

我的态度：会购买，会尝试，但是不太看好。苹果押了注，但是能否成功，任重道远。

从 P1103R3 之后，Module 在标准化上就通过了一个比较重要的提案 P2465R3 （将标准库 module 化），而之前听过一个大佬的分享，实际上从有到能用到堪用再到好用，还有很长的路径要走。

比如，随便可以举出来好几个问题：
1. 最基本的，编译时间、增量编译和宏的兼容方案？
2. Module 的 cache 产物统一：目前 gcc (gcm) 跟 clang (pcm) 跟 MSVC 是完全三套，先不提如何兼容，这离 Module 想达到的目标还很远；
3. 如何分发产物？如果分发 .so ，跟现在的情况有什么改变？如果分发编译 cache ，怎么在经典的 ABI 、Linking 等等问题下保持可用？如果需要用户单独编译，那为什么不直接分发源码？
5. 现有的工具链如何兼容适配？编译优化（ ccache 等），包管理（ conan 等）以及相关的 module 生态等，目前都没有一个明确说法。

至少在我看来+乐观估计，得等 5~10 年，等到这些问题有一个解决方案，才能达到堪用水平，我们才能说“C++ 有了 Module”。

意识拷贝（意识上传）——容器不同，但是内容相同，是否认为跟原始个体相同？ https://www.wikiwand.com/en/Mind%20uploading#Philosophical_issues

忒修斯之船——容器相同，但是内容物使用相同的替换件进行替换，是否认为跟原始个体相同？ https://www.wikiwand.com/en/Ship%20of%20Theseus

都是比较经典的哲学问题，才疏学浅，只提供 Reference 。

Netflix 关于 IRA 和 401k 的纪录片，《 Money, Explained 》 E05 ，Retirement： https://www.bilibili.com/video/BV1964y127ZC?p=5

@GeruzoniAnsasu

刚注意到有个 context miss 了，我也补充几个点：

- 使用 mpsc 跟 spsc 是非常简单的，一个基于 token 的 bucket 可以简单控制好 task 的数量，共用 token bucket 就可以控制每个 spawner 的数量。注意到这里也可以简单地基于 chan 封装一个，不需要所谓的阻塞队列。
- spawner/worker 基于 message passing 的 channel 可以解决所有 promise 的场景，包括超时等待等。
- 所谓的全局 channel ，js 的 microtask queue 和 marcotask queue 同样是全局的，甚至基于这两个场景你如果需要定制化 queue 的调度逻辑你需要对 runtime 有更加深入地理解，而 go 基于 token bucket 做定制可以做更多的事情。

@GeruzoniAnsasu

针对你的 task ，准备一个跟结果一直长度的 []chan 就可以了，扫一遍每个 channel 就可以针对每一个 chan 的阻塞策略，很直接。https://go.dev/play/p/YbtujcTry_J 。

至于 Promise ，你需要的只是一个 Task 结构，注意到结果本身是否 ready 可以依靠超时 + channel ，解决，封装一个类似的结构是 naive 的，在 github 上能找到非常多的类似的库。

可以去看一些官方 talk 理解 CPS 机制的原理，而不是尝试把某个机制 mapping 过来。

文件系统是对底层物理数据存储的抽象，本质上是一种协议，这些 section 上的数据可以用这种协议解释。在不同系统上使用同种协议可以挂载同一个区块，最终写完了都在同一个物理区块上，那么换到其他系统（甚至直接 `dd` 到一个 image ）上打开，只要协议一样，读取到的内容是一致的。

而 OS 本身跟文件系统是半解耦的：本质来说，OS 跟文件系统应该是完全解耦的，你也可以在 Linux 上使用 NTFS 。但是对于现在用的比较多的三大 OS ，都对自己常用的文件系统有特定支持（例如 Windows 的 Bitlocker 对 NTFS 支持最好，一些比较有意思的扩展特性例如 Alternative Data Streams 可能其他平台的 ntfs 实现不包含），所以本质上来说跟 OS 关系大也不大。

所以，文章的问题可以回答为：
- 保存在物理区块上，跟操作系统无关。
- 在不同操作系统下，只要有协议的实现或者兼容层，读写应该不会有太大问题。
- 现代 OS 对自己常用的文件系统可能大多有扩展，对于这些扩展，在其他平台的兼容实现上可能有问题。

Go 实际上编译生成的函数只是在语义层面上跟原始类型绑定，而在之后的代码生成过程中，Go 隐式生成了一个对应的函数，这个新的函数跟老的类型是解耦的，并把对象本身作为第一个参数传入。

举个例子来说，考虑你的测试代码，Go 编译器会生成下面的 stub：

```go
func (*A).Run(a *A) {
fmt.Print(a.a)
}
```

这种函数签名是你不能写出来的，因为在用户层面这种语法是 invalid 的，但是你可以调用。尝试在你的 Test 中插入：

```go
func TestA(t *testing.T) {
var a *A
a.Run()
}

func TestAnother(t *testing.T) {
var a *A
(*A).Run(a)
}
```

代码可以正常编译执行，然后报错。

而假如我定义另一个方法，不访问 A 的内部参数，即不依赖 A 的值，你会发现代码能够安全运行，没有任何问题（ 16 楼老哥已经有 runnable 了）。

这种情况是不是比较反直觉？而实际上 GCC 和 clang 也是这么做的： https://godbolt.org/z/xb9WWz53x 。当然，如果你打开 undefined behavior santizer ，你会发现编译器报错了，因为标准并没有对这个情况作出规定。

所以是否需要检查 receiver 是不是 nil ？取决于你。如果这个方法你不想 panic ，那你可以检查 `if p != nil` 并做出恰当报错，但是这会影响大家对于 method call 语义的共识理解（如果 a 为 nil ，我调用它的方法应该 panic 啊？为什么没有 panic ？）。或者直接 let it crash ，也方便查错。

续了三年，吃饭的工具还是愿意买单的，而且也确实好用，虽然我现在主要用的最多的也是 vscode 。