VS 自带 IncrediBuild ，不过不顺手我不用。
然后是预编译头文件。
还有 mozilla 那种 unified build ，不过不是所有源码都能用。
剩下无非的加机器和 ramdisk 这种通用的，以及不要用太耗时间的优化（不过 cl/link 这块还好）。
限制 VS 其实多少得自求多福了。否则 gch/ccache/sccache 那套明显更舒服。GNU ld 特别慢还可以用 lld 或者 mold 。
@lance6716 要不得不用到自己魔改的 go toolchain 照样会吃亏。

似乎是 Web 界面 merge ，如果要改你的 PR 把分支拉下来再自己改动好 push 上去其实也和你这个 PR 没关系（就算 commit message 里提到了 issue 效果也是 closed ），所以不如直接先 closed 了。
另外有时候改动数量太多的时候根本没法 Web 上点 merge ，强行要 merged 得先先 (force) push 一个让改动数量足够小的 base 版本才能在 Web 界面上 merge ，然后再 (force) push 想要到的最终状态。
感觉 GitHub 这里多少有点弱智了……

TOTP 2FA 又不是没 PC 的解决方案。
你只是担心硬件损坏而不是泄漏被还原的问题，为什么要考虑非要硬件载体？而且一个手机不行大不了多买几个备用机呗，又不会比专用硬件贵。
而且说实话如果不是自己手搓的，我反而不大信任一般的硬件。瑞士在这块名气大是因为隐私保护法完善，可不表示技术实现一定靠谱。Crypto AG 也是瑞士的吧，被 CIA 窃听几年了……

@wasd6267016 你想搞事情么。
对普通用户来讲，不想做 FSF 抠脚皮大汉输出意识形态的，就不需要号召。
而且不合作本身就是一种意识形态的表现，这种方式作用的效果可以相当于诛十族——针对的不是厂商，还包括养肥这些厂商的市场。
具体操作是，随便遇到一个人，被我发现没对 QQ 浏览器有意见，甚至对此还表示支持？行，那你不是脑子太不好使就是良心大大滴坏，简而言之就是非我族类，就算不和我做对，你死活原则上不关我什么事，要有什么事不要指望热心给你提供什么资源了。若要是不得不关我什么事，要么给我利益交换足够无视异族习性的生理厌恶，要么就是我发挥家长制作风直接包办替你干掉了，要么就是你最终被我无视掉。
说白了，商业公司欺软怕硬，我也可以啊；我没本事让腾讯消失，远离让我不爽的人还是做得到的。

@llwwbb7 我见到的不管是或者不是周围的都有人去实际行动过，效果不忍直视；而我本人看不起把持 Go 的核心人员的工程不作为，所以不屑浪费精力肉包子打狗，这也解释得很清楚了。
直说吧，WG21 现在的提案质量大多数都相当垃圾（什么没事整个 char8_t 改 string literal 类型后进到过了几年知道有 bug 了认怂回档但是发现进不了 deadline 还得再等 3 年进下一个版本）到一人一票制下我都懒得关心（而是不得不提 defect 擦屁股），我又不用你 Go 赏饭吃，外加你个 Go 对整个工业界的那么丁点（还嫌多）的存在感，你个 Go team 也配碰瓷我工时？
就算不清楚别人什么水平，想不到这点，那你看过文章了没？对 Go 不爽的 Go 用户去试图提意见改进的这篇文章作者就干过，然后什么效果？
那么，你呢？
有没反思过我为什么评价你高高挂起？因为你在这就没什么行动，撺掇别人上，自己光说不练，也没说清楚你有什么立场光说不练。

@james122333 不说立场，你得先弄清楚对事实状况有个基本了解才有讨论的意义。现在就鸡同鸭讲。
Go 哪来的异常，连 Rust 那种烂掉的 union type 都没。Java 的 checked exception 是滥用语法重载（偷换 try/catch 的含义）的阉割版 union type ，都够流毒无穷了。
基本知识问题麻烦善用搜索引擎，不浪费字数了。
我就再提点你搜不到的：异常和续延背后的东西是控制作用(control effect) 。不论静态类型还是直接不支持，那就是在恶心健全的用户，因为想要克服这种限制原则上只能自己掀翻重新造一个不那么无能的语言。要是用户无能到想象不出还好（虽然考虑到这些限制的普遍性，我就看不大上自己没搓语言的用户的观点），想要剥夺已经被享受过的自由，那只能靠愚弄了——一如纯 FP 语言鼓吹者对传统命令式语言用户洗脑“副作用是邪恶的”。
Rob Pike 这种尚且能被不会独立设计出的普通用户黑出翔，至少语言品味上的道行显然不值得我评价；最高也就是道不同不相为谋，但这是贬低的不是他一个人（他不配；其实 Go 都不是他自己的作品，黑他主要就是水平烂见识短），而是所有自甘堕落因为自己想象不出该怎么不对无能的语言妥协就恶心别的用户的卫道士的总体。至于 Plan 9 ……，（以整个 OS 作为大号语言运行时的实践）历史地位上就还是算了吧。UNIX 什么 everything is file 是比鼓吹 everything is object 影响还大点，我倒是有黑过。

@llwwbb7 我就奇怪你有没有视力问题，更奇怪为什么还有人给你点感谢。嘲讽？

原文：
> Go 语言社区里，有一大批 Go 语言的推崇者和脑残粉丝，他们满足于现状，不思进取，处处维护心中的“神”，容不得批评意见，不支持对语言的改进要求。当年我对 Go 语言的很多批评和改进意见，极少得到他们的支持，他们不但不支持还给予打击，我就纳闷了，他们难道不希望 Go 语言更完善、更优秀吗？连基本阅读理解水平都你不知道还好意思分享了？

看完文章你就该知道 Go 的支持者对维护者以外的人做出的改变（不论是否是改进）的大概的态度了。

Go 社区拉一般用户仇恨根本不是个别现象，也很少有别的语言社区能作到这个程度的，如：

https://github.com/hhstore/blog/issues/348

虽然那个普通菜鸡水平只能让我归类为“一般”用户。

不那么一般的么，比如信创行业要为 go 上游放置某些国产后端 issue 几年不鸟、工具链实现质量炸翔的原因，要把 Go 厨二挫骨扬灰的也有——毕竟屎淹到脖子以上了，看厨二还能呼吸得逍遥自在，不爽也不是不能理解。

相比之下，你这风凉话就是事不关己高高挂起的小丑了，连 Go 官方都不如——后者好歹还在做事，虽然未必做人事。

@wheeler 妄自尊大的 UNIX 无知厨二出线一次，没被人人喊打，即得而诛之，免得路人习以为常传染反智病毒。
有个更明显的例子：{ 不换行要往上缩，为什么 } 还要单独占据一行？有厨二所谓“省行数”，当诛，因为这是侮辱智商：真要省行数为什么不用 LISP style 把 } 缩到上面一行？
再者，为什么 K&R 风格控制语句的 { 和函数定义起始块的 { 换行规则不一样？这也是厨二解释不了的。真正的原因其实是早期 K&R C 的声明语法造成的上下文差异。K&R 厨二八成连 K&R C 都不会，殊为可笑。
不屑评价这种无聊问题，本是正常状况；但遇上自己脑子里没货还非得硬洗的，要哪壶不开提哪壶污染视线怎么办？除了直接镇压没什么更有效的做法。虽然我仍然时常希望不用每次我来普及那么入门的基础，但什么都不做只会更差——要是没人反驳，搞得反智者就天然有资格指鼠为鸭了一样。
不经大脑以讹传讹者同罪。

@james122333 这其实是个很有讨论价值的话题。
首先，你意识到异常可以用“封装”实现，已经可以碾压一堆麻木不仁的无能用户了；但就有个直接的问题：被封装的是什么呢？
有没有想过，大多数语言设计者会去考虑直接内建异常，就是为了逃避被封装的对象在理论上的理解门槛（都先不用考虑异步异常的复杂性），或者更甚——压根就想象不出这些东西？
先告诉你结论：在有可变状态（比如能赋值修改对象产生副作用）的语言，异常可以用一等续延(first-class continuation) 配合实现。而更基本的有界续延(delimited continuation) 可以凭空在语言里添加类似赋值这样效果的可变状态支持（当然这不是纯 FP 语言，续延调用本质是一种副作用）。加上定界的原语，直接用控制作用搓出整套异常也不是不行。（顺便，现在那些 FP 人搞什么 algebraic effect system 其实是 delimited control 炒冷饭。）
为什么一般所谓的工业界语言不这样做？除了不够方便利用硬件实现外，最主要的原因就是——那些语言设计者太菜了，这点基本的弯弯绕绕都不会。而 Rob Pike 在这方面其实就属于平平无奇的太菜者之一，偏偏还比较喜欢不懂装懂（虽然这里没有特意显摆如何犯傻；别的像区分不了 nominal type system 和一般 type system 已经是普通用户都能领会的语言设计业界的笑话了）。
结果搞笑的是，这些设计者看不透复杂性具体在哪，聪明反被聪明误。一个实例：像 C++ 这种语言 spec 内建异常看似不弯弯绕绕简单了，实际上 ABI 黑魔法一大堆，并且几乎阻止了绝大多数有现实意义的优化（以至于使“异常”多背了几倍性能差的黑锅；其实就是 bad path 本来也不需要那么差，更重要的是 C++ 异常烂不表示没有更正常的，比如 ML 系的那坨）。——注意这种优化不只是 ABI 过度设计问题，current_exception 这样语言上的机制也有锅。知道菜人占据主流地位的危害了？
当然，理论上异常也是有一些不方便被续延之类的控制原语取代的性质。这方面么，有篇入门读物 Contrasting Exceptions and Continuations 。入门以后大概就容易理解为什么虽然 C++ 那种异常设计已经足够欠揍，还是要更鄙视“连异常都没有”的无能语言了。（当然，有续延自然论外。）

@haolongsun 你不用自我评价来体现你眼界不足的优越性。
你所谓的 Linus 是哪个？我是不清楚有什么配来评价的行家叫这名的。别的出名的，不管是 Linus C. Pauling 、Linus B. Torvalds 还是 Linus G. Sebastian ，不管在别的领域有多大成就，在这方面就是外行；如果不算你显摆无知外，和你说白了是同一个级别的菜鸡。
什么是内行呢？比如说至少也得徒手搓出 computation model 。
像 A. Turing 搓过 Turing machine 就是个这种 model ，但对应的语言就是 Brainfxxk 类似物，显然品味不咋地。他的老师 A. Church 搞个 λ calculus 就能把他吊起来打，因为比起除了 Turing machine 和 λ calculus 分别都独立起到极其重要的历史作用的 Church-Turing Thesis 外没实用性的 Turing machine ，λ calculus 事实上定义了高级语言——它能扩展出绝大多数实用语言，不论这些语言的设计者有没有意识到。而 Turing machine 可没多数人意淫的超然地位，同时代的现实的 computer 都根本就不参照它设计，就没起到演化出 computer model 的作用，如 C 厨二随便一个 PDP-11 式的 PRAM(parallel random-access machine) 都能把它摁着摩擦，刷存在感抢功劳还有点在看不起至少在 EDVAC 就明确区分外存和内存的 von Neumman ——尽管 computer model 比 computation model 天然次等，而且这还不是他一个人搞出来的。（其实 Turing 也搞过早期的 computer model 然而多少被无视了。）
但即便是 Church 这样的行家，也会有掉链子的时候。他曾经鼓吹 λI calculus 代替 λK calculus ，就是因为逻辑侧的完美可推理性质的执念导致不能表达偏可计算函数，因此后世还是用 λ calculus 指代 λK calculus 而非 λI calculus 。绝大多数已经受到前置严格训练到能手搓新 model 的专业人士，同样在天赋上就突破不了 Church 的这种程度的历史局限性。
回过头来看，你所谓的 Linus ，不管是哪一位，比起 Turing 的水平，还不是被随便踩扁的蝼蚁？而 Turing 在高级语言计算模型设计的码品上不过是个菜鸡不如的小角色，都不知多少人好意思拿他代替 Church 的地位。然后你还有脸在武力值早就突破 Church 这个层面能取得系统进展的行家面前提什么玩意儿？
连手搓语言都不会，也配来洗地？

@wheeler 影响视觉体验和阅读代码效率，我是觉得和强行缩进一样欠揍。

@Maerd 简单粗暴，我喜欢。

要我就得说 Rust 那坨屑 union type 也是大便； Java 好歹有 exception 了但 checked exception 也是一坨不地道的 union type 伪装的大便； C 艹现在干掉了类似 Java throws 那坨 dynamic exception specification 了但是有 current_exception 和 __cxa_get_globals 还是大便（大概和 call/cc + globals 实现的 exception 差不多臭）……

满目都是没有脱离时代局限性的大便，偏偏大便和大便的差异还挺大，要细细品味分析成分还是有些绷不住。

正常点没那么多消化半成品的错误处理应该是 first-class delimited control 之类的（也有 algebraic effect system 之类的冷饭正在流行），外加 local mutable states 可以实现的 exception ；至于 idiom 可以看刘未鹏的更上古老文。

@iceheart 长是什么？你喜欢的东西对你也许是够，对有本事自己造全套方案的，那就是吸引小朋友骗流量的生态垃圾。到底是谁的毛病？
就 go 那坨 variable 和 object 都拎不清的 spec ，能改？连 spec 都没二次开发（比如 C++ → C++/CLI ）的价值的玩意儿，实现又是一坨（包括整个项目维护都有问题，loongarch 一坨问题 patch 交上去常年没人鸟），不整个弃还留着发酵呢？

@Rooger 哦，路个过……我创造过不止一门，你创造了？那么我不闭嘴，你闭嘴？
（做梦，Rob Pike 假充内行在这里都不怎么配被我多送流量。）

可以淘汰别人啊……
既然还问得出来，说明对过程不是毫无感觉的。

@xfxz op 给了你多少……你不说我甚至都没发现广告。。。

@yagamil 根本不是你理解的这样。就因为这种冗余的元数据的选取跟语义独立，所以才困难。因为这种东西就是给人看的，机器原则上不可能检查（除非是具有比你更强 NLP 能力的真·强 AI 到直接能把你淘汰的那种），你不可能预知别人看了会跟你想得一样，更不可能保证你的命名绝对是最优解，光是确保能满足需求的工作量就触及了“软件工程的本质困难”。一旦要添加能影响语义的特性（比如反射），又是一地鸡毛。
当然机器原则上不可能检查的东西多了，比如怎么让 GC 代替显式资源释放的位置。但是没有一个其它问题的普遍性能和命名困难相提并论。（如果有，那么最接近的是如何定义相等操作。）

1.2.3. 没用过接近的机器，没遇到类似问题，无法评价。
4. 不 root 用安卓找啥不痛快啊。不过我的系统比较近原生本来也没内置广告，app 开屏的没几个，网页平时基本不用，也懒得动。
5. 也就这个是纯软件问题。然而平时基本用不到网页看视频，甚至没注意到……（有说 iOS 强的我也没法确认。）

@kiwi95 其它语言能不 crash 是有代价的，在 memory safety 问题上基本都依赖 GC （倒不需要 lint ），极少部分是 region-based 但基本没在工业界有显著性。依赖 GC 导致的 STW/latency 问题一直就没真正彻底解决过（总不能让用户都上 TB 级别的主存用 Azul C4 吧），就算现在可以不是主要问题了，RAM 利用率低下导致客户端开发从来都很糙，就不可能是正确的解决方向，只能是 workaround 。更要命的是依赖 GC 的代码在资源分配边界上缺乏不变量的混乱导致的质量问题，原则上是不可能解决的——你要非 GC 语言移植到依赖 GC 的语言直接干掉内存释放都行，反过来试试？实际上不依赖 GC 会迫使实现者分析清楚用 GC 不可能自动解决干净而本来就要人来决断的逻辑问题，设计的完善程度就是不一样的。一旦依赖 GC 就注定是半吊子实现，如果不能排除未来有更严格的质量需求，那基本得重写，提前背负这种风险相当不值。
所以实际上光是要避免这些实用问题，比较有存在感的语言也就 C 、C++、Rust 了。然后算上其它可维护性和管理成本选哪个？（这几个语言的 lint 也没多少用。） Rust 也就是矮子里拔高个，因为剩下的编译器做得更少，就算写起来简单点，review 成本更高。当然如果什么人都不缺可以直接 C++ ，不用跟 rustc 斗了（只要有本事兜得住 ICE 和依赖管理之类乱七八糟的破事就行）。

@chesha1 不，刚好相反，我首先不怎么有兴趣对连 prioritize spec 都搞不定的项目做贡献。Rust 能有显著性，只因在座的各位（在对付 memory safety 等问题上）更加辣鸡，所以显得 Rust 在对付不听话的 coder 节约 review 成本上有奇效。但是……我本来就不需要对付这些人。
另一方面，Rust 确保 safety 依赖具体 ad-hoc type system 的设计的欠缺灵活性是我直接不爽的——比如没法单独要 memory safety 而无视 concurrency safety （即便我甚至可以证明某段代码就是单线程下跑的），导致一些简单的写法不 unsafe 就表达不出来——如果时常考虑 unsafe 那我干嘛还要允许 rustc 浪费时间？所以我都不会拿 Rust 的设计过来抄，而是当作反面教材用。
至于没有兴趣折腾是很正常的，主要不是 Rust 的问题——而是因为一些基础设施不管用什么语言重新实现都很无聊，耗费资源又大，既然原来的东西不是烂到没法用，就没什么人有动机来推了。
比如这里很多东西依赖 CUDA 吧，但你也没法说老黄一直能嘚瑟，等写得差不多了，新一代跨设备的行业标准来了怎么办，岂不是 49 年入国军？关于 GPU 这方面软件栈长期选型问题都是传统艺能了，DX 还是 GL ，GL 还是 Vulkan ，要折腾迟早都要踩一遍坑。别人非得对付是因为有具体项目需求，我又没有，现在有了也可以用现成的凑数，又不是没法用。那么为什么不当等等党，拖着减少要踩的坑的绝对数量，等到有确定的具体项目需求发现不得不重新造了再说？

@FrankHB 还要做个语言限制的修正。
上文所述的 API ，不仅仅是环境中提供访问的函数名，明确包括形参名称这种 lambda calculus 中唯一提供的命名（ bound variable ）的方式。
实际情况是，具名函数的函数名被当作 API 的一部分，因为它指称的对象（函数）的内部结构是默认封装的，所以也就函数名以及类型这样的外部特征允许标识(identify) 一个 API 了。更何况还有基于具名函数的 ad-hoc polymorphism：重载。
然而函数以外的普通的对象的表示其实也是封装的，甚至某种意义上是更加封装的，内部结构同样不保证总是清楚唯一（ ABI 的意义上例外）。那么为什么这些对象名不是 API 的一部分？因为两者的实现难度存在差别：实现的语义等价变换会重写函数体（或者 basic block 之类的变体），但是重写更一般的对象内部结构会依赖更困难和特设(ad-hoc)的方式来证明语义等价而不属于标准的优化技术（比如把整数和浮点数类型相互替换需要证明计算结果没有误差没有 fenv 副作用），所以一般不考虑。因此，把一个非函数的对象的结构暴露到 API 层次，容易混淆接口和实现的边界。所以就算全局对象作为 API 的一部分，一般也不会提供字段这样的内部表示，而是具体函数功能的一部分配置（典型例子是语言提供的标准流对象）。
但是，参数名在实现内部实际上还遵循一种更特殊普遍的 API：naming convention 。大多数情况下，只有一个函数形参命名成 x ，只要没其它嵌套作用域冲突，就已经够可读了。循环不变量的 i 、j 、k 同理。要强行提供更具体的命名反倒不一定更清晰，因为原始目的就没有这个意思。这种约定在大多数语言中不被视为 API ，因为大多数语言压根就没提供足够的反射机制来对变量名直接进行操作。但是，如果语言允许局部的完全反射并提供充分的操作（如 Lisp-like 的 symbol->string/string->symbol ），对代码对应的 AST 直接进行元编程，应该怎么命名变量名的 pattern 就是 API 的一部分。只不过这类 API 基本只会在自动化代码审查的元程序中用到，而且通常不像函数名和类型一样会被提前静态检查。
其它语言中这种情况相当少见，不过不是没有：例如 C 的宏允许做字符串拼接生成参数；例如 #pragma GCC poison 。无论如何，这些只能生成而无法反射的用法都相当恶心，所以缺少关注。