噢对了补充下，我知道做优化的时候有至少一种情况会把 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，然后说祖传引擎不好改，干脆就弃疗了
说白了还是一核有难七核围观 ...

Anno 1800 和 Factorio 是”同类型”的么……

哦对漏了一种，就是本身就是服务于“语言本身”的项目，如编译器，运行时，开发环境等。

你这不都是 JS 的项目么 ...
一般一个项目起始的时候，起名字是不会和语言扯上关系的。
但是有一类项目，是把其他编程语言中的特定项目用另一个语言重写 /移植的，或者对标其他编程语言的特定项目，就经常会用和这个编程语言有关的元素修饰项目名（不一定是直接用语言名）。
或者没有明确的原型项目，只是项目的最主要特点就是用这个语言写的（换句话说就是没啥其他亮点 ... 或者说大部分特点都是和语言强相关的），也会用这种命名方式。还有一个类似的原因是项目作者命名能力就是捉鸡，想不出啥好名字。只能用个通用的名字+语言相关元素来命名。
还有一种项目是不实现具体功能，但是只做对其他编程语言中其他库的 binding，这种很自然的一般用 编程语言名 + 库名 的形式命名。

上述现象在新兴编程语言中极其常见，因为新兴编程语言建设生态会有很多类似项目。
而 JavaScript 的崛起史基本就是一部抄袭史，所以在 JS 社区慢慢就成了传统了，就连 React 这种基本原创的项目，大家也叫他 React.js 。
（其实 Java 里面也不少 ...）

或者说，站在项目作者的角度看，你写这个项目，如果是为了“解决某个问题”，那么一般就会以这个问题为出发点命名，如果是为了“*在某个编程语言里*解决某个问题”，那么命名时就会倾向带上和该编程语言有关的东西。

不是“可以搞”就“一定要搞”的。

据我所知，Clojure 最牛逼的应用是 Datomic，一个利用 Datalog 技术的数据库。也是 Clojure 的创造者 Rich Hickey 搞得
而该应用的一大硬伤在于，他是闭源的 … Cognitect 公司需要它赚钱来投入到 Clojure 中，而另一方面如果一个语言的 killer app 是闭源的，那么必然会严重影响该应用和该语言的应用（虽然我很怀疑任何一个 LISP 在现在能有什么大的应用）