多线程写入，结果就是写入的数据不可靠，不是直接给你报错。
只有你再使用写入的数据时才会把问题暴露出来，而在实际程序中很难知道是谁什么时候写入的数据，这是并发错误难调试的原因之一，报错的点不一定是 data race 发生的点。

有时候也会故意这么做，性能会好一些，

@agagega 很不幸"基于正则的语法高亮"在我这也是要淘汰的 ...

我举两个类似的例子：

引用 https://v2ex.com/t/612874#r_8089400 这里面的：
> LLVM 一开始用了以 camelcase 为主的命名方案，具体来说是类型名，变量名（包括局部变量和成员变量），用 UpperCamelCase，函数名是 lowerCamelCase 。
> 但是后来发现一个问题，比如我有一个变量的类型是 MemorySSAUpdater，那么按照命名规范，我不能把它命名成 MemorySSAUpdater，因为会和类型名冲突，现在的解决方案是取首字母 acronym 命名成 MSSAU 。这种情况在整个仓库里十分广泛： https://github.com/llvm/llvm-project/blob/734c74ba14be0f4421ccd9f720e5b9309248e0f7/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp#L709 感受一下
> 但是这种命名多了就会十分奇怪，看代码必须先要熟悉这些奇怪的缩写才能看得下去

> 于是现在有个 proposal 就是把变量命名从 UpperCamelCase 变成 lowerCamelCase，这样我就直接命名成 memorySSAUpdater 就行了： https://llvm.org/docs/Proposals/VariableNames.html

当时这个事在邮件列表里面吵了半天 ...

同一帖子上一楼提到，一些函数式编程语言强制要求某些结构使用特定的命名规范，比如在 OCaml 中，constructor 和 module 的名称必须以大写开头，而 Haskell 中类型和 constructor 必须以大写开头。刚开始学的时候感觉有点奇怪不过没太在意，后来也就习惯了。
但是后来我自己写语言抄 OCaml 的时候就发现问题了，通过这种语言设计上的小动作，编译器实际省下了很多工作——正则一匹配就知道这个标识符到底是个值还是个 module，同样是命名空间的访问，value.field 肯定是访问一个 record 中的值，Module.value 肯定是访问模块中的值，Module.Submodule.value.field 肯定是嵌套模块访问 + record 访问。
而类似的问题在 C++ 中的解决方案是引入两种语法结构： "::" 用于静态命名空间的访问，"." 用于实例命名空间的访问。
现在我自己要解决这个问题，要么抄 OCaml 的，把命名规范搞得不像个“正常语言”，要么学 C++ 的，多占几个符号，多加几条规则，还有一种方法是我 parser 开洞，不通过任何语法层级的东西来 disambiguate，不过那样 parser 跟 C++ 的就差不多屎了。
现在我已经放弃在文本层面解决这个问题了 ...

@Mithril 哪个蠢驴
是瑞典的那个么，那个主要应该是祖宗之法不可变的问题
还是波兰的那个，那个主要应该是管理的问题
这种优化手段应该对这种大量重复元素的场景是比较适合的，其他的效果不一定好，期待后续文章。

另外还有一个思路是分流，因为一般意义上的“群”从概念上来说是一群人围绕某个主题集合在一起（这种事情貌似是要有关部门批准的？），但是由于群不是职业性的，所以一般”人”要比”主题”更突出。到最后就变成二选一，要么人要么主题，但是人明显是最根本的，所以选择“主题”的，一般我们称为”死了”。
Discord 在这方面做得就不错，Discord 中的群是”人+弱主题”，在群中再细分”频道”(貌似是这么叫的)，也就是强主题，但是同一个群中的频道共享一群人。一般 IM 是群=>聊天窗口二级 UI，Discord 是群=>频道=>聊天窗口三级。比如搞一个 V2EX 群，就可以有 C++频道，Java 频道，找工作频道 etc. 这样缺点是频道多了之后一个个关注会比较费劲，但是几乎所有群都会有一个”offtopic”频道。这样吹水也不误，正事也不误。存人失地，人地皆存。
（频道多的自然解决方法也很简单，就是搞一个聚合频道，然后你会发现这特么不就是 V2EX 的 IM 版么……）

如果你想做到”干货比例大概在 70%以上”，同时还想有人说话的话，至少有两种方式：第一是做梦，第二是研究时间机器——总之就是想办法穿越到另外一个世界去
如果想做到干货比例 60%以上的话，在本世界线倒是可能的——从把每一个撤回消息的人禁言一天开始

这个问题和面试是一样的

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

然后看能不能把面试官唬住，唬得住 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 么 ...