@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 。

Ti7000 之前掉盘了，朋友的 PC005 自己用了帮别人装，一年多了没出过问题

@lxdlam 没有换行写的有点乱，最后一条 case 和 default 是不同的分支

Reading Material： https://go.dev/blog/pipelines

拆成两个问题：
1. 多个 goroutine 如何读取消息
- 使用 fan-in 和 fan-out pattern ，将其结果汇总到一个 channel 里，此时原始 goroutine 关闭 channel 不影响；
- 直接 select 多个 channel 。
2. 当某个 gorutine 退出时如何通知其他的 goroutine 退出：
a. （可选）如果需要等待其他 goroutine 退出的话，使用 sync.WaitGroup 等待；
b. 使用一个 exitChannel （ chan struct{} 就行），接收到退出信号的时候直接由 main close ，其他 goroutine 使用 `for { select { case <- exitChannel: return default: logic} }` 的形式来正确接受退出信号