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 整个语言的发展历史来看，为了一些之前没考虑到的事情，动态开洞擦屁股这种事，也不是发生一次两次了。但是这条回复的目的还是给大家一个清晰的认知，也建议讨论设计问题前，先搞清楚前因后果时间脉络，减少鸡同鸭讲。

这个位置一直漏电，都习惯了

支持了，如果能看到 TV 支持就更好了哈哈

Copilot 对临近 context 的学习能力很强，写日志和监控的输出、接口的相似实现实在是太好用了。虽然核心逻辑始终现在的 AI 还是不够好，但是大量的人力工作也就是在写这些纯模板代码上，确实帮我节省了大把时间。

有一种可能是跟屏幕一样，8G 跟 2x6G 混用了，然后软件限制都是 8G 。目前应该只拆了一些机器，所以不好说，看看后面有没有更多人拆

@lxdlam 有一定差距 -> 有一定不同

Zookeeper 不是 Paxos ，而是自己发明的协议 ZAB ，跟 Paxos 有一定差距；实现了 Paxos 的系统有很多，比如 Google 的 Chubby 和 Scylla DB 。

同样，根据 DDIA 的说法，现代 CAP 其实逐渐式微，因为现代系统设计里面这三个每一个话题都会有很多需要考虑的问题，不再只是单纯的 3 选 2 了。

@ShinichiYao #28 如果 Key space 足够小且 IV 的 space 也足够小的情况下，知道一定的 plaintext 才是可以攻击出密钥的，这个叫做 Known-plaintext Attack 。

在已知范围内，如果不满足上面的结论，AES （所有模式）都免疫 KPA ，这是因为 KPA 的一种最直接的攻击就是遍历 key 跟 iv space ，尝试每一种可能的 combination ，如果都在 2^16 这个级别，现在的好一点的家用电脑可能不需要一晚上时间。而在现代实践中，AES 一般使用 128bit 及以上的 key ，这种情况下即使 IV space 较小，攻击难度也非常大。跟知道多少 (plaintext, encrypted) 无关。

Reference： https://crypto.stackexchange.com/questions/100521/for-aes-gcm-does-knowing-plaintext-and-ciphertext-allow-attacker-to-learn-the-k

零知识证明。

@kuanat OCaml 有两种数据对象，一种是传统的函数式对象 Record ，这个是 nomimal 的，类型 tag 区分不同类型，而 object 和 module system 是 structural 的，实际上我例子中提到的函数可以这么写：

```ocaml
let print (bar : < foo : string; .. >) = print_endline bar#foo;;
```

注意到这个独特的签名，其实要求 `bar` 需要具有一个特定的 foo 即可，对其他的都不要求。

@lxdlam oops ，应该是 #10 ，看错楼了

@lxdlam 补充一点，Go 的基于 Signature 的 interface matching ，实际上 OCaml 早实现出来了，即使是 First class module ，也是 2011 年引入的，早于 Go 。

```ocaml
module type Foo = sig val foo : string end;;

class a = object method foo = "A" end;;
class b = object method foo = "B" end;;

let print bar = print_endline bar#foo;;

print (new a);; (* "A" *)
print (new b);; (* "B" *)
```

不同意 #14 的说法，实际上 #14 所需要的只是 Composable 的 interface ，而并不是所谓的 duck typing 。

引用原文：

> - Don't implement Interfaces preemptively.

在这里提到的 case 实际上是因为，Java 由于无法对任意 External Type 实现 Internal interface ，所以如果原始的行为 Contract 没有被声明为 Interface ，我们既不能实现我们自己的替代品（有 interface 的情况下，实现一个 Adapter 不就可以了？），也无法使用我们的 interface 去将其替代；而这个限制在 Rust 中已经被放宽到不允许使用 External struct 去实现 External trait （ https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type ）。

而 Go 这种 Duck typing ，实际上比起 Java 的显式声明，是另一种推卸责任。举个例子，假定我存在两个 interface：

```go
type Visitor interface {
Saw() bool // If we have seen this node
}

type Sawyer interface {
Saw() bool // Can sawyer saw?
}
```

当我实现 `func (???) Saw() bool` 的时候，我究竟在实现谁？这大大加剧了误用几率，反而在工程上是一个 bad practice 。（这种 case 一定存在，参考 Hyrum's Law - https://www.hyrumslaw.com/ ，一个行为只要被足够多的人观察，无论是否跟你的设计和想法保持一致，一定会有人在依赖这个行为）。

如何回避上述行为？一种方案是实现一个空的 method ，限定其在特定 namespace 下面，比如：

```go
type Visitor interface {
Saw() bool

IsVisitorImpl()
}
// ...
```

但这跟 Java 的 `implements XXX` 相比，无非是把这个 Tag 下推到 `interface` 内部了，本质是完全一样的。

而如果实现细粒度的 `interface`，#40 提出了一个很好的例子，我们甚至可以：

```java
public interface Putter {
String put(Item item);
}

public interface Getter {
Item get(String key);
}

public class Storage {
private Putter putter;
private Getter getter;
}
```

虽然有点累赘，一样实现了类似的细粒度接口组合，并未有任何功能上的差异。

看 op 应该是 Oracle

猜测 union 查询命中了联合索引，所以不需要对 `datetime` 排序，只需要决定起始位置就可以直接 fetch 数据；而 IN list 先对命中三个条件的数据进行 merge ，然后 sort 后再筛选，无论是合并、排序操作还是需要扫描的行数（ 8989K > 2123K+180K ）都远比前一个查询计划大。

一种可行的优化可以尝试 over partition 拆成三个子表排序再重新 where 一下，不确定优化效果，需要再 explain 一下看看，参考 https://use-the-index-luke.com/sql/partial-results/window-functions

家里 Apex Pro TKL Wireless
公司 宁芝 Micro84