这个问题和面试是一样的

面试的时候你先大吹一通，就类似：
> 珊瑚海配色和牛油果配色 ... 蓝牙

然后看能不能把面试官唬住，唬得住 50k，唬不住 5k

VSCode 有正常，给编辑器写小插件的成本一般远小于给 IDE 写

我猜用 flex 和 bison 的一般都在用 vim/emacs ...

看图感觉是桌面左上部分出现了一个透明的窗口把事件挡住了的样子……

感觉可能是表格组件为了获取某些参数会做这么一个临时设置，拿到之后就会恢复原来的设置，但是这个过程出 bug 了
应该可以以 body 的 overflow 样式变化事件设置断点做做文章

倒是学学 C++可能对”创造编程语言”有更实际的帮助

如果你想”创造编程语言”，也不必熟悉 LLVM……

噢对了补充下，我知道做优化的时候有至少一种情况会把 32 位数故意 widen 成 64 位，就是频繁转换的时候。
具体来说，是一个循环的 induction variable （ https://en.wikipedia.org/wiki/Induction_variable ）被定义为 32 位，但是使用时总是先 cast 成 64 位再使用，这种情况用 64 位数代替原来的 induction variable 可以省去转换的开销，并且就一两个变量一般都放寄存器里面，做起来才值得。
（嘛不过我只是观察到这么一种行为，并没有找到对应的参考，也没有仔细看相关的代码 ...）

叫 John 吧

仅就 x86 而言，int64 还真不一定比 int32 快
“快不快”不仅仅是指令支持的问题，数据宽了一倍，占用的缓存空间、内存带宽都加了一倍。如果真有一百万个这样的数，可能还真是 32 位好一点，特别再考虑到 SIMD 的情况下

如果这货的行为真的像楼主说的一样“在 64 位处理器上占 64 位，在 32 位处理器上面占 32 位”的话，那么看 C/C++ 是正解，不过鉴于大道至简的 Go 目标之一就是干死 C++，估计没人会去看的。

C 里面有一个类型叫 size_t，相当于 Go 的 uint，还有个 ptrdiff_t，相当于 Go 里的 int （假设楼主说的行为是对的）
size_t 顾名思义，可以装下任何对象的“大小”，比如在 32 位环境下，地址空间中不可能存在多于 2^32 个唯一的对象，一个对象的大小也不可能超过 2^32 字节，所以 size_t 做成 uint32_t 就可以。需要存大小、数量时就用这货。
ptrdiff_t 顾名思义，可以装下任意两个指针相减的结果，需要存偏移时就用这货。（不过 C 标准里面貌似没有保证，毕竟真正存差值需要 wordsize+1 位 ...）
毕竟如果是 32 位环境，用 64 位数存数组有多少个元素实在太过奢侈了，这时候根据大道至简的原则，就可以加一个类型叫 int 。

这只是一个猜想，因为 Go 的所谓 spec 实在太大道至简了：
> uint either 32 or 64 bits
> int same size as uint
反正在这两句话我是没找着“在 64 位处理器上占 64 位，在 32 位处理器上面占 32 位”的保证。因为他把这玩意写在后面 builtin functions 部分了：“The built-in functions len and cap take arguments of various types and return a result of type int. The implementation guarantees that the result always fits into an int.”，然后就有了这个 https://yourbasic.org/golang/int-vs-int64/ 。也就是说这个类型和它的角色并不直接关联，可能本来设计者的想法就是从 C 里面随便捣鼓来的 ...

你说的不是 Actor Model 么 ...

"fp 爱好者“表示，可以去看一下 TAPL 的 “Imperative Objects” 这一章，这一章使用带简单 subtyping 以及 records，references，fix 操作符等基本扩展的 lambda calculus 对“面向对象”的基本行为进行了“approximation”。
我看的时候总有一种初学 JavaScript 的逮虾户 ...
但是最后最 tricky 的是 open recursion 的模拟（作者将 open recursion 归为 OOP 的“fundamental features”之一），这个是以前看 JS 教程的时候没有意识到的——这东西在大多数非 FP 语言里面几乎是天经地义的事情，我也 take it for granted 了 ...

而且你工作需要 Linux 又不一定非得是 x86 的 Linux……

不如期待下这个 https://asahilinux.org

查了下资料，好像 macOS 把某种内存又分为了“活跃”和“非活跃”两类，需要换出到交换区时应该会优先换出“非活跃”页。iStat Menus 里面的“实际可用”搞不好“实际”把“非活跃”给算进去了。

楼主不如给个 Activity Monitor 的截图 ... 因为我这没有新版 macOS，也没有 iStat Menus
根据网上的截图，macOS 的 Activity Monitor 把物理内存占用分成“已使用内存”和“已缓存文件”两部分，而“已使用内存”进一步被分为“应用内存”“联动内存”和“已压缩”三部分，所以楼主的实际物理内存占用是“应用内存”+“联动”+“已压缩”+“缓存”，which 差不多接近了 16GB 。
这个“活跃”就不知道是哪来的了 ...

只有我觉得 GitHub 的代码搜索非常不好用么 ……

@himself65 #6 我怎么看怎么感觉他说的是 false sharing，然后说祖传引擎不好改，干脆就弃疗了
说白了还是一核有难七核围观 ...