@musi 不大会这样，因为 js 自己调试工具够成熟了大部分人本来就不需要认识 wasm ，而且 wasm 就不是给人方便读写设计的。

@msg7086 原则上像样的项目所有有实质改动的 commit 都最好走 pr 有别人 review ，再缺人那也得至少涵盖涉及不同 owner 的多个 branch 的 merge ，否则一旦出问题，锅就只能是 merge 的人背了，那就有点……活该了。
横竖都是一个人的项目锅都会自己背（虽说不该有并发提交的冲突），不过这种时候一旦吃亏就很容易长记性。
至于没搞清在干什么就敢 push -f （或者说，就敢允许非仓库配置管理员 push -f ），那是整个 team 在另一个次元意义上的活该（尤其是掉 commit ）了。

@msg7086 这种 merge 出问题一般不见得那么麻烦，因为正常人都是遇到很少的 conflict 马上能处理完才会去耐心直接在 merge commit 上改（否则改了一半又有人提交就犯二了），而且 commit 本身不见得就很大。只是做了任何不能自动解决的操作都应该在 commit message 里说清楚。这样真有问题，大不了直接拎过 parents 手动重现。其实效果就是相当于把之前某个 parent 的最近的 commit 给 squash 上来了，如果改动直观到是个人就能看懂就无所谓，反正这种 merge 本来就得人工验证而不可能全自动化。反过来，有时候能自动解决的反而可能是错的，这是更坑的炸弹。
要是真是遇上脑子不大正常的，那就得拖过来教育扣工时了。

@chaowang 这还真不是 js 的问题，头铁也可以强推 wasm （虽然 wasm 有另外的技术问题）。
关键是（只）会 js 的人就不干了……

@catalysia 我指的是 1940~1950 年代年代的早期数字式电子计算机中通常被当作冯·诺依曼机鼻祖的具体设计。
还是不清楚你说的最原始的是指哪个。实际的 EDVAC 在 1949 年交付，外存是磁带（一说磁性钢丝），直到 1954 年才升级支持打孔卡 I/O ，1955 年支持磁鼓。（题外话，最早的直连磁记录的键盘输入设备 UNITYPER 在 1952 年就能用了。）

我强调的是，即便是这类最早期的实用设计，也是区分两种 memory 的。原因很现实：考虑延迟和持久化要求，没什么同时适合担当两种部件的物理实现——甚至到现在也很少见，以至于仍然有物理内存和硬盘的差异。
即便现在所谓的冯·诺依曼机习惯上不那么强调不同的 memory ，在这个问题上仍属于横插一杠——要在体系结构上消除两类存储的差别，通过随意模拟经典的冯·诺依曼机凑数是不够的。

至于翻译，首先要看是否准确达义，约定俗成是在歧义不会阻碍理解的情况下才轮得到考虑的次要的方面。不论是特性还是 bug ，在阻碍主要需求的时候都应当尽量排除。
如果不是无路可退，就不选择有歧义的翻译，至少是避免卖弄半吊子语言水平增加歧义的翻译（比如什么“堆栈”）。而这里并不属于没词可用的情况。
现在的状况是已经够混乱了。比如问一个 C 语言用户：寄存器(register)属于 memory 吗？硬盘空间可能作为 memory 的一部分吗？继续放任混用就容易凌乱。
所以在我经手的技术文献中，memory 通常就翻译成存储。

@catalysia 原型机……你说的是 First Draft of a Report on the EDVAC 里的具体设计？那反而更不支持你的说法，因为里面 CA 、CC 、M 、I 、O 、R 这 6 个部件是分离的，明确区分 M 和 R parts ，CA 、CC 和 M 相连，而 R 得通过 O 中介。至少考虑拓扑结构，这里就自始至终都无法让 M 和其它存储部件平级，除非是你把 R 抽象掉合并回 M 作为实现细节，然而就算是今天的物理机器都没这样（甚至软件上也只有 IBM System i 等少数实现做到了统一 M 和 R ）。
后来所谓的冯·诺依曼机的共性其实无视或者至少明确削弱了这点（要义在于“程序存储”，CA/CC 都能访问 M ，而不在乎 M 和 I 、O 、R 之间怎么配置），但是实用体系结构研究中要求具有一定的静态属性以便能取得比较具体的配置（≈能造出相对固定物理形态的设备以及设备互联），所以习惯上我没看到有按你说的怎么用那么 ad-hoc 的分类。

翻译请求是泛化了的体系结构才会关心的，但也就是因为这里的判断准则也是“程序存储”这种“能力”而非当前实现的功能。只要你的 CA/CC 部分足够弱，在一个实现冯·诺依曼原始设计的或者其扩展的机器上可以强行拒绝实现这些功能的指令而重新移除这些功能，但这不表示这种机器的物理配置不是冯·诺依曼机。这里完全都是同一种体系结构（纯粹的冯·诺依曼机）来说的，改变的配置都是实现细节。
倒是 model of computation （而不是 model of computer ）会有类似你的思路，但基本上也不会叫 memory ，而是叫 store ；而且很少有动态配置，因为这些抽象机对应的大部分原生语言的核心语义规则都不支持动态配置，至少不会动态掉干掉活动记录和 store 这样主要的存储部件。

内存当然很自然地是 internal memory 的直译，对应这里的 M part ，这没什么问题。但原始文献中其实 memory 通常专指 M 但是有时候又同时指 M 和 R （比如比较 M 和 R 说明为什么需要区分两者的时候），所以歧义一直就有，原则上不可能不多加对应关系就翻译对。
我的意见是既然现代观点大部分用户（软件作者+最终用户）接触到的 memory 和 internal memory 是两回事，那么就不要混起来，只有少部分历史上下文才有容忍需要消歧义的必要。
主存也是自然的说法，因为 M part 在后来的设计普遍就被拆分了，特别是几乎所有用户都没法对主存以下的存储编程，所以要严格就不能无视主存和 cache/寄存器的差别。然而所有这些部分自始自终都是“内存”。把主存和内存混在一起就不可能自然，只能解释为体系结构误解太多，不能编程的部分（容量又那么点）用户平时就忽略了，即便它们的日常作用就非常重要。

补上漏了的结论：严格意义上 memory 叫内存不合适。但是手机的存储空间实际上是内存+外存，把存储和内存对立技术上也是错的。
程序员还应该注意内存使用到非主存的物理实现。主要编程语言通常只能操作默认的地址空间，不可能排除寄存器和缓存，甚至连 swap 都不保证能可移植地排除（一个副作用是按字节访存忽略内存延迟都不保证 O(1)，悲……）。

存储容量单位的差异不重要。钦定用 IEEE 词头就不会有歧义了。不精确更多是系统 UI 惯出来的。
但是不是所有存储都支持按字节寻址。这个意义上倒是更应该注意，空间上 1B 和几 bit 没有固定换算关系。常用体系结构默认 1B=8bit ，但是并非一直如此。ISO C/C++支持至少 8bit 。POSIX 重新限制回 8bit 。而具体存储介质上就更不固定，比如算上纠错码，光存储的 1B 实际可以超过 10bit 。

题外话：WM 时代时的 ROM 空间就已经被叫 internal memory 了。这才是“内存”的正经原文。

@catalysia 需要纠正一个错误：不是所有联机的存贮设备都可以叫做内存。
上面提过内存和外存的界限是能力而非联机状态。对冯·诺依曼机，能力指能被控制器直接访问，你的例子中需要另外的设备翻译 I/O 请求，就都不算内存。只是现在大多数都是混入了缓存的修改哈佛结构，算是加了不少飞线，甚至还有两用的设备（比如傲腾），这个情况才真正在体系结构上模糊界限。这个界限通常在 ISA 之下（缓存对 ISA 以上原则不可见）。ISA 的编程接口向上可以虚拟出内存设备，但已经不算是冯·诺依曼机了——而是更具体的寄存器-存储机和其它具体编程语言对应的抽象机。

大多数程序员仍然需要了解的组成原理科普：

每个程序员基本迟早都得了解存储的层次体系(memory hierarchy) ：寄存器(register) 、缓存(cache)、主存(main/primary memory) 、辅存(secondary memory) ，即便大多数语言完全不区分其中的种类，但是对实际质量影响太大了做不到全部无视。
但仍然应该注意通用语言不鼓励你强行区分实现细节，所以讲 memory ，程序员首先需要理解可能是以上的任何一种——即便 main memory 是主流实现的最常接触的 memory ，也不应该混同。
memory 比较正常的翻译就是“存储”（ storage：存贮）。对面的“记忆体”也还行。“内存”是个很差的翻译，本义是在线存储(online memory)，指 secondary memory 前的 hierarchy 。但是约定俗成对应 memory 也罢了。对应的“外存”是指离线(offline) 存储。离线是指能力(capability) ，而不是指状态，所以你硬盘就算一直加电联机也叫外存。内存和外存指一般用途，是和存储体系并列的分类。

另一种分类关于物理特性。最主要的大类是易失(volatile)/非易失(non-volatile)。外存要求使用易失存储实现。具体元件分为锁存器 /SRAM/DRAM/ROM 等等，这些和存储体系不完全正交，但属于另外的分类。

大多数情况下，主存是使用 DRAM 实现的物理内存。这是操作系统或者独立(freestanding)实现（或称为 bare-metal ）的应用会看到的主存视图。对应用，典型情况使用虚拟内存空间，即经过被支持地址翻译（通过 MMU ）的体系结构地址翻译映射的空间。这些空间实际来自于物理内存以及辅存中的交换空间(swap)。有些实现，如 IBM system i 直接使用 128-位地址空间，把主存和辅存都编址到同一个地址空间提供给应用。大部分常见实现都仍然不支持以相同的方式访问主存和辅存。
值得一提的是，辅存可能不是外存。虽然罕见，辅存也可能是易失存储并作为内存，例如 NDS 的 Slot-2 扩展 RAM 卡。使用这类扩展内存通常需要一些特殊的编程技术。

@seanzxx 这个图虽然罗列了不少要点，但是都放在一起技术上并不正确。另外，一些实现其实会按驱动类(driver class)区分设备，而并不对应图中的具体分类。这种分类下设备可能是虚拟的。

把主存叫做运行内存技术上不算错，但根本是冗余的。

看到 U 就不用看了。UNIX 哲学本来就一大滩糊涂账，能直接整个拎过来当锤子抡的直接盲猜没理解什么 UNIX 哲学的外延——果然不会冤枉。
所谓一个程序做一件事不就是 SRP ？而一坨命令行参数什么时候成了正面示范了？不就是你 shell 语言弱鸡才让程序自己 parse 命令行参数？而这正好不就是混淆 shell 和 shell 应用的 SRP 的反面教材？真扯 purpose ，你能先整个允许把 purpose 定义为程序实体作为 first-class object 传的像样的语言代替 shell 再吹好不？
UNIX 还有一坨 everthing is a file 和 file 内容默认一坨文本的垃圾习惯。比如你写代码要按照那坨文本厨二排除 BOM 那实际上就是故意 type unsafety 双标搞事。幸亏原作者的脑洞这里还不够大教坏小朋友。
UNIX 哲学还包括信任程序员，该 UB 时就 UB ，这直接和“与期望一致的行为”矛盾。目的论上，被 WG21 的 narrowing contract considered harmful 之类的教条吊打。
DDD 该用的地方基本就是 D 出来应付外行；其它情形就是拖延简化问题的义务，让自己装作外行，这经常根本就是反模式——譬如说，增加一大坨不 man 就别想清楚干啥、又跟其它命令不通用的 domain-specific “专业”命令行选项。没有对滥用打预防针就是失败的，joyful 那是想多了。

SOLID 虽然日用混沌到像空话，至少 LSP 之类还是有坚实的理论基础的。就这点漏洞百出的理解，这坨 joyful 何德何能跟 SOLID 碰瓷？

在做一个像样的推广 UI （看来还依赖 Chrome 系的……）前请先拼写对 World 。
……看了下，官网里 run Hello World 标题是对的，示例代码里没拼对。

@Suddoo @iosyyy .
节约铜币，直接挂 gist 。
https://gist.github.com/FrankHB/93304e6fd8db29e6368e32a1922205c7

@Building 加上镰刀，可以绑定装备了……

@Aloento 变成桶子去找 coser ，多好（

@Suddoo 提到 Java 就让你想到辩护，而不是第一时间 me too 自己发现罄竹难书的问题，这种对思考能力的摧毁效果就够臭了。
正常的语言基本都是要么没人用要么都会骂。提到缺陷一头雾水的，几乎可以断定用得不够多和不够熟练。
至于别人骂的具体什么对你就未必那么重要了。比如我会骂所有静态类型语言设计残废，因为遇到类型系统的局限性我不能直接在语言里扩充而需要换语言，浪费时间看这些设计还不爽。比如连同像性都没还需要特设什么反射的傻大个看着就二。再如一开始设计者拎清楚常识没给 lambda 没 closure 就硬塞什么 class 什么 method ，结果事后跪舔又加进去的，增加维护 spec 和实现工作量的弱鸡语言就是该骂。又如钦定全局 GC 还有脸写客户端 GUI 应用逼最终用户调优的就是寻衅滋事。我都觉得特意针对 Java 掉价（甚至我对 Gosling 表示嫌弃因为他对 vi 有贡献而不是发明了 Java 都够了），然而这些 Java 就是不能免俗，还是典型恶俗代表。
但是我说的对你有意义么？你来混婊语言界？

@ipcjs 经验如此。我没具体 profile ，不过我猜跟操作进程开销的多少有些类似，Windows 应用操作文件用的 API 经常套娃太多层了，干了很多不需要干的活，不像 Linux 本机应用一般系统调用往上 libc 套一层搞定。不过差距不会像创建进程那么夸张。当然资源管理器慢起来那是真的慢……有时候我都直接 dolphin& 了。

我是 Windows11 的 SB2 （这个实例有毒，Win10 时就 80072F8F 没法自动更新和进商店，更新 Win11 便笺也废了，一直懒得全新重装），因为屏幕好使，远程 Win10 的 G14 ，开发环境 MSYS2+WSL1(Arch+KDE)。VMWare 备用。
只要日常不是写内核驱动 /FUSE/systemd/个别系统调用 /依赖显卡加速或具体外设 /非 x64 应用，WSL1 基本爆杀全场，还不用担心滚挂……（虽然但是最近 node SIGILL 挂了好像还没解法）……最欠抽的小文件性能也比原生 Windows 强得多。原生 Windows 和 WSL2 或者虚拟机都要吃点各种性能的亏，要再快你就基本只能直接原生 Linux （但反过来要部署到 Windows 就基本得要虚拟机了，Wine 还是太感人）。

下标的问题，只能说历史丈育太多，典都不知道，还用得着举例了：www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
Lua ？算哪根葱……况且 Lua 用户自己很多就不满意：lua-users.org/wiki/CountingFromOne
再有争议可能还是数学丈育更多，分不清基数和序数。

至于枚举……谁告诉你枚举就非得有从几开始的问题？
还是 C 枚举当整数，于是随便什么语言都需要关心编码？
（ Swift：？）
而且咋不学 C 把 char 也整成整数类型呢？

@byzod 太臭了，要肛掉。

@murmur 我用的 Surface Book 2 的内存也像金条似的……而且当年 16G 到顶了……
因为价格太感人所以 SSD 也没 1T 顶配。
结果被我手机（红魔 7P ） 18G+1T 双杀。

（现在 mstsc 的 G14 有 40G+1T 还能忍……）

@wxlwsy Surface Book 2 用到现在我已经熟练掌握了鼓包顶开屏幕后拆下屏幕电池放气然后使用双面胶粘回屏幕的操作手法了……
屏幕还行，也没拆坏，所以一直 mstsc 。