> The static type (or just type) of a variable is the type given in its declaration, the type provided in the new call or composite literal, or the type of an element of a structured variable.

静态类型是变量声明时的类型。

> Variables of interface type also have a distinct dynamic type, which is the (non-interface) type of the value assigned to the variable at run time (unless the value is the predeclared identifier nil, which has no type).

接口类型变量还有一个动态的类型，这个类型是运行期赋于的*值的类型*，除非那个值是**预先声明的标识符 nil**，它没有类型。

这里很明确地区分了 标识符 nil 和一个值的类型。


解释了把 （标识符 nil ）和 （一个为 nil 的值）赋值给一个 interface 的区别，前者没有类型，后者值为 nil 但是有类型。


> Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value nil.

两个接口值只有在动态类型和值都相等时相等。

不明白为什么一个现代的语言还满地的 nil 。

也不明白为什么需要知道它的实现（接口值是类型+值 blah blah ）才能理解它的行为。

能不能根据 The Go Programming Language Specification 来解释一下这个行为？

实在不行你可以编译成 wasm 然后用 wazero 执行。

直接支持全部 Go 特性，直接用 Go 编译器编译，通过 wazero 暴露方法给它调用。

用 migrate 管理，但不自动执行。

用 sqlc 生成 db 模型和查询。根据需要可以手工映射一次，隔离 db 实现。

用了一段时间，然后在主力机放弃了。

我通常会开浏览器，编辑器，terminal ，然后需要快速切换，完全用横行的话切换就很麻烦（也许有 shortcut ？）。另一种就是一个 workspace 放一个应用，然后 Mod + N 切换。结果就有了一个二维的窗口管理，略复杂。

非主力机还在用，开箱即用，也方便我关内置显示器。

提个 CI 的改进 PR ，直接用工具（例如 typos ）检查整个仓库的 typo 。而不是每个（或每几个） typo 提一个 PR 。

AES-256-GCM.

GCM 是 AEAD ，在密钥不对的情况下，它会告诉你密钥不对，而不是强行用错的密钥解出一堆错误的数据。

即暴力试 2^128 次就能解开第一个密钥，再试 2^128 次解开第二个密钥。而 AES-256-GCM 需要 2^256 次。

所以两次 AES-128-GCM 并不能提供 256 bits (2^128 * 2^128) 的安全，只能提供 129 bits (2^128 + 2^128)。

你用过 Go 的 math/big （或者其他 decimal 包）就知道了，他们的加减乘除是这样的：

```
func (z *Int) Add(x, y *Int) *Int
func (z *Int) Sub(x, y *Int) *Int
func (z *Int) Mul(x, y *Int) *Int
func (z *Int) Quo(x, y *Int) *Int
```

本来一行就能写完公式，你用上面的 API 要不断搞中间变量，硬是写成十几二十行，每次写点复杂的计算公式或者 code review ，我就头大，非常想要运算符重载。

@zeusho871 目前 llgo 对 go 支持不咋地，连 fmt, net/http 这些都没有 :(

之前有人做过测试，以 C 为基线，Rust 的运行时检测大约带来 1.77x 的损耗，其中 bound check 大约占 50%。

https://dl.acm.org/doi/fullHtml/10.1145/3551349.3559494

用 outbox 模式，把消息也写到 db 。

@NessajCN Rust for Linux 做的就是 kernel api 封装 + high level 抽象，说是调用也没问题。

如果 Rust 不进内核倒没这么多问题了，让 Rust 开发者改调用的就是了。

但是 Rust 进到内核之后，C 开发者和 Rust 开发者的合作就会有很多问题。C API 改动导致 Rust 代码编译不过的话，怎么办？放着不管？ 让 C 开发者学 Rust ，改 Rust 代码？ C 部分的开发、设计会不会受 Rust 的影响和限制？。。。

@NessajCN bindgen 生成的只是 low level binding ，还是 unsafe 的。像 25:29 那些 safe high level API (get_or_create_inode) 还是要手搓。如果 iget_locked 真的改了（虽然我觉得这个 api 基本不会改了），手搓的部分还是要再搓一遍。然后实现就会不同步。

@matrix1010 想起来为什么没有用 x/sys/cpu ，因为它的 cacheLineSize 是私有的，只能用 CacheLinePad ，浪费了一点点内存 :|

@matrix1010 对。x/sys/cpu 会根据指令集决定。 刚看了源码，也是因为 Apple Silicon 改成了 128 :)

就差把 amd64 也改成 128 了 :(

看到里面实现了一个 Counter ，然后加了 cache line pad ，cacheLineSize 写死了 64 。

但是 Apple Silicon 的 cache line 是 128 ，所以还是有 false sharing 。

然后 Intel 虽然 cache line 是 64 ，但是 prefetcher 一次可能会读两个 cache line ，而 AMD 又没类似的优化。

还有些大小核 cache line 不一样的。

所以现在常见的做法是 ARM64, AMD64 都假设是 128 。

参考：
- crossbeam::utils::CachePadded 的 PR： https://github.com/crossbeam-rs/crossbeam/pull/636, 顺藤摸瓜可以找到很多讨论
- https://github.com/embedded-momo/fastcounter-go 一个类似的 Go 实现，固定 128 cache line 。