说起来这个 Rob Pike 的素数筛法应该思路就是当年 CSP 1978 这篇论文提到的素数算法，以前欧长坤老板做过 CSP 1978 论文解读的分享，里面就有素数筛法的例子，论文当然是自己的 CSP 语言，而他写了个 Go 版本：
https://github.com/changkun/pkg/blob/f787593b4467793f8ee0b07583ea9ffde5adf2be/csp/csp.go#L833

这应该单纯是个闭包问题：

1. ch 变量本质上是个 *hchan （ https://github.com/golang/go/blob/ed035af7b7d7c1cd2e6f852e22a9b04fc2a2cc65/src/runtime/chan.go#L34 ），是指向 make(chan int) 也就是 runtime.makechan 创建的 hchan 的指针。

2. 直接使用闭包引用 ch ，ch 发生了内存逃逸（因为是 go func ，我 -gcflags="-m" 看了下确实逃逸到了堆），你在闭包 go func 中使用 ch ，就是在操作 ch 指向的 hchan 。

3. main 函数后续 ch = ch1 , 也就是 ch 指向了原本 ch1 指向的 hchan ，导致 go func 操作的 hchan 也发生了变化，进而整体程序没有按照预期执行。

4. 而正确的实现 Generate(ch)，以及 func(ch){...}(ch) ，是函数传参，是将 ch 变量值复制传入到了 Generate 或者 go func 里。

如果你去看汇编，这次 ch 就分配在栈里（ main.ch+40(SP) ），在运行 go func 之前就把它的值复制到寄存器里供函数使用了 （ MOVQ main.ch+40(SP), CX ）。因此后续 main 里 ch 针对 hchan 的指向发生变化不会影响 go func 内部，值复制保证 go func 内部指向的 hchan 不变。


感兴趣自己可以看下汇编研究下，我也只是大致看了下：go tool compile -S main.go > assembly.s

看需求更接近开发一个上报监控指标的 agent ，逻辑上应该比较简单。
解决资源问题（内存）可以看下 tinygo ，算是针对嵌入式环境的一个 go 编译器实现，如果没有用不到 go 关键字、反射等特性的话应该问题不大。

中午饭吃饱，下午喝些茶、咖啡，或者水

感觉大的可能的收益是在二进制序列化协议（ protobuf ），一般外部接口感觉是在传输 payload 比较大的时候可能会考虑使用，类似 Prometheus Remote Write API ， 一次请求可能是几 MB 或者几十 MB 的写入，Protobuf + Snappy 压缩，也可以像 VictoriaMetrics 使用 zstd 进行压缩，当然传输协议其实还是 HTTP 。

我不是做移动端的，看了下 Android 的文档也确实有 gRPC 方案的文档介绍（ https://developer.android.com/guide/topics/connectivity/grpc ），但也不是主推的样子。加上上面很多老板提到的调试成本、学习门槛，以及弱网下 grpc 可能会存在坑，导致看下来 grpc 在客户端通信通用场景的优势并不明显。

和楼上说的差不多。

MediaPipe 有 Google 开箱即用的人脸识别方案：
https://ai.google.dev/edge/mediapipe/solutions/vision/face_detector?hl=zh-cn
https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/web_js?hl=zh-cn

然后你检测摄像头有人脸（或者划定一个关注识别的 rect 里面有人脸的话，基于识别到的特征点来判定）就认为你坐着，然后过几十分钟就弹出来提示。

另外工具的话一般我就用 jetbrains 全家桶，开箱即用，Ctrl+B 下钻函数，Alt+F7 查某个对象某个函数在哪些地方被使用了，Ctrl+Alt+左方向 上翻自己上一个跳转，Ctrl+Alt+右方向 下翻自己下一个跳转，Shift+Shift+Shift 全局搜索，这些基本够用了也挺好用的。

我看代码都是记笔记的，而且是手写书面笔记（可能 ipad pro 记笔记也不错？）比如一个章节就是介绍某个函数或者某个类的，这个函数分成几个部分，又调用了哪几个函数，然后下钻的函数再分别记笔记……

如果理解的部分就不需要抄代码直接用自然语言描述下，不理解的部分就标注待后面回过头看，或者查资料（ gpt 、源码分析）来综合理解。

手写笔记有个好处可以翻到前面去和当前下钻的函数和新理解的代码做对照，可能之前不理解的部分看到后面结合一下一下子就理解了。

看完一个部分后可能会找网上的源码分析进行对照，看看自己还有没有什么疏漏的地方。

不记笔记的话还有种办法就是写博客，自己从头介绍一个功能、一个模块的源码分析，这样实际写博客要讲给别人的时候就会知道哪些概念自己还不明白。

当然这些都算是笨办法，效率不是很高，但从结果上来说是让我可以理解、看得进去代码的，而且这也是个热身的过程，随着对于代码理解得越深，很多笔记就会越简略。

不光是运维成本，微服务间调用本身也是开销（还要引入分布式追踪来保障可观测性），且如果拆分服务粒度有问题还会引入分布式事务等可能本不必要的复杂度。

IT 圈一直会一阵一阵过热地吹捧某个技术，但很多场景只有最合适的，没有最好的。

感觉这是目前 copilot 类应用的普遍问题：codebase 的上下文限制。
不过不知道是不是我们这边的错觉，感觉 github copilot 使用下来准确率下降了很多，而 cursor 在写小项目时还是挺理想的。

fastcache 的方案是 mmap 自己申请管理 kv 的内存，也绕过了 gc 。

但是它的 hash -> idx （ bucket.m ） 索引本质是个 int->int 值类型的 map ，如果特别关注 gc 的话可能还是有一点优化的空间。

重要的是对应岗位经验对口，现在的行情是八股全对但业务履历对不上的话一般也很难要。

@cloudfly 我也不大习惯类似很多 Java/C# 项目这样的复杂的抽象，也可能是自己脑子不好不大擅长设计这些 hhh
包括 Kubernetes 源码也有点这味，相比于阅读 VM 以及 Go runtime 的代码，会很不适应。

像 mmap ，作者在 18 年时候就提过 Golang 使用 mmap 的问题： https://valyala.medium.com/mmap-in-go-considered-harmful-d92a25cb161d
但我最近看源码发现其实现在 VM 还是会用到一点 mmap 的，并在注释中说明在实际生产环境中这么写还是 ok 的：
https://github.com/VictoriaMetrics/VictoriaMetrics/blob/025eec2cb00381b5292d34601f96d7fcf7503191/lib/fs/reader_at.go#L81
具体情况如何后面我想写点 benchmark 梳理看下。

@cloudfly 是这样，老毛子做东西抛去了很多繁文缛节，同时没有过多封装和抽象，读的时候感觉应跳出一些思维定式和权威崇拜的桎梏，很多主流的方案未必没有优化的空间。

以及 VM 作者让我感觉 Go 的上限其实不低，即便不用 C++/Rust 也还是可以通过 Go 写出性能满足生产要求的代码（当然前提还是对于计算机系统、网络等有足够深刻的理解）

我应该会把 VM 系统性读完后去把记录的一些优化技巧和调参梳理下，自己写 benchmark 多进行验证（比如频繁使用 sync.Pool 以及序列化时将数据梳理在一个大 []byte 里带来的局部性…），然后再去看看 fasthttp 的部分……当然，更进一步来说，通过这种阅读也更进一步认知到自己对于系统、网络理解上的不足，后续还是要继续钻下去。

点赞，近期刚好在看 VictoriaMetrics 的源码，感觉受益匪浅，很多性能优化技巧可能自己也需要做些 benchmark 再思考验证。

翻译工作如果有需要的话我可以帮忙做一些。

笑了，我就是余姚人