为什么非要制造瓶颈？这种简单任务你用 C 临时糊个都不用几分钟，省下几个小时不香吗……

不是没有，比如 Atom Z25x0 。但这种设计现在基本不面向手机市场。手机 SoC 的 CPU 流行大小核。
HT 之类的 SMT 实现主要就是利用片上冗余资源换取性能，冗余的部分主要是执行单元，共享前端导致支持 SMT 下单线程性能会被献祭。手机 SoC 这种本来就为了节约能耗提升能效并且极端节约面积，不会考虑刻意允许物理冗余来照顾增加并行计算能力（特定计算密集型的任务会上专用 ASIC，后台服务直接用小核跑），SMT 增加复杂度还缺少场景用得上，得不偿失，基本就不会这样设计。
要是以后规模能耗能 hold 住上 SMT 也不在乎这些副作用了，再考虑文艺复兴。

@siteshen 他说的是“研究文法”，大概是类似 Chomsky 那套，通过搞自动机实现分析器对应的元语言来代替语义规则的描述，那当然是拙劣的妄想。作为解释自然语言结构的尝试的文法来讲还多少有点用，但对搞 PL 来说是没什么意义，因为自然语言几乎演化没有设计，跟由明确需求导向的实用的 PL 需要的可操作的方法恰恰相反。
实际上，也找不到任何一个能算是流行的工业语言是按那套方法来设计和实现的；任何像样的形式文法都自觉局限于确定语法，妄图僭越这个来干预语义的无一都是拉仇恨（看看 C++ ，连严格的形式语法都撸不出来……）。

喜欢研究，研究出了什么都不会说一下？
还有挺奇怪的，你哪来的自信钦定有没有用？
比如说，作为常识，知道现有的辣鸡怎么没用就是一种“有用”，因为这至少能影响选型成本。
所以怕是其实根本从头到尾就是在自 high 吧……

只是睡不着？
拍个片，配止痛药先整到能睡着。止痛药不明显就打封闭。大多数情况下水肿期不用让你撑一整个月。然后看是不是能长期保守治疗。
手术可能复发更快。

发现这些分析之中都少了一个原因……就是用户到屏幕的距离很可能比以前更近了。
现在分辨率普遍提升的情况下用户有更多的选择，不少用户就习惯缩小文字以显示更多的内容（或者干脆默认使用高分辨率以适配更高的设备 PPI ），但当某些时候局部太小又不清晰时，多数人一般不会去用放大镜之类的，而是凑上前看……久了就凑得近了。
明视距离短到一定程度，比较宽的屏幕没法一眼看清，还要麻烦颈椎，当然拉仇恨。
至于换行……主要是自动折行普遍没法照顾布局逼的。有条件当然最好避免莫名其妙的硬回车，但编辑结果的兼容性就呵呵了。

@yuikns 按我看到的一般的常见的用法，serializing / deserializing 指数据结构的内部表示和（至少）允许串行访问的外部存储的表示（尤其是直接对应外存中的可持久化格式，如文件映像）之间的转换； marshalling / unmarshalling 则强调系统内处理的以既定方式访问的数据（通常就是语言运行时支持的一等对象(first-class object) ）和系统外的表示形式（不限制格式是否公开稳定，不强调持久化，具体支持和语言之间互操作的要求有关）的交互。两者外延不同但有交集，条件允许时可以共用一套实现。

划分 I/O 操作的基准要看什么是系统“内部”。I/O 是指保证对外部有不可忽略的影响的操作。否则，找不到一个外延去限定什么才能算 I/O，字面含义也说不通。
有些操作作为 I/O 是没疑问的：产生可观察且无法保证消除的行为（比如说，总是需要消耗电力）的物理设备发生的通信是真实的 I/O。
除此之外，还可以假装认为存在其它类似的影响外部状态操作，以实现不可控的“外部”系统交互。例如通用操作系统的内核把设备驱动排除出这里的“内部”，统计的所谓 I/O 可以包括仅在虚拟设备上有意义的操作；为便于设备驱动实现和统计方式的原因，这种假定姑且是合理的。
但就不提供让用户显式指定如何处理的计算作用(computational effect) 大多数编程语言来讲，没有说得过去的理由这样装。特别是 C 和 C++ 对这种“外部”副作用已经专门用 volatile 区分了，再含糊地给库函数开洞只会导致不必要的劣化和库 API 设计的混淆。

@Takuron 没有 Root，都是弟弟。
过审有过审的流氓姿势。

@GeruzoniAnsasu

serialization 序列化
deserialization 反序列化
marshalling 列集
unmarshalling 散集

翻译不是问题，只是因为没多少人用所以才用原文。问题是原文意思就被普遍用错，而这个错误来自权威来源。
具体来说，I/O 是指系统内部和外部的交互。在一个系统内部交互的作用强行称为 I/O 会引发混乱。
这种误用的典型例子是，以抽象机语义指定行为的 ISO C++规定 I/O 操作（“库的 I/O 函数”）引发副作用——不管其实现是否改变了抽象机这个系统的状态。
这不科学。因为至少像 std::stringstream 这种（ ISO C++所谓 Input/output library 里的）东西本来就不应该和系统外部交互，在这个定义下因为钦定副作用可能影响可观察行为而没法被优化成 no-op，即便实际可能什么都不用做。
再如，像格式转换之类的功能本来就该是 serialization/deserializaton，是应该能够证明不必要就该消除的东西。
真正的 I/O，是和设备交互的操作，操作的设备这种抽象机以外的接口。
这个意义下，C++的标准库 I/O 原则上设计就是错的，因为它违反了核心语言要求的抽象边界。让所谓标准 I/O 库函数比用户实现的 I/O 函数具有更加一等的地位也不可能是目的，何况在这里根本还没法直接优化。
这个问题从 C 就有，不过大概 stdio 隐藏了缓冲所以才没那么明显，以讹传讹惯了……

真要“一键”应该只能买给你 root 过的，按开机键……
现在新机出厂的大概都不行吧。

想知道粘包警察是何种文化输出……樱警察 /车万警察 /厄介警察？
另外倒是想出警把 serialization/deserialization 或者 mashalling/unmarshalling 和 I/O 混为一谈的……

看来和我理解的差不多。
按我的口味，我不喜欢 try ... catch ... 这种要求语法上是内嵌“代码块”。技术意义上，这种 try 和 catch 必须是“语法”，其中 ... 不能一等对象，因此整个基本上不得不用宏实现（如 https://gist.github.com/sebfisch/2235780 ）而不能拆分成函数。
不过都打算直接内建在语言里写死了，这倒是无所谓了。

这么多楼跑题了那么多，也就半个说到点上的。
控制流(control flow) 在很多时候是个有害的概念，因为过度片面强调程序（源代码）反映的静态结构对程序运行状态的影响，反而给理解添乱。
摆脱这个刻板印象，最直接的方式是在判断程序如何运行的问题上，使用续延(continuation) 的概念代替。（当然，这个理解偏差问题更多毒害写静态语言编译器的，一般用户一时间理解不了也犯不着死磕。）但除非打算实现控制操作符(control operator) ，这里还不需要是一等(first-class) 的。
恐怕对大多数看不清“回调”意义何在的用户来讲，这里真正需要被理解的首先是一等函数(first-class function) 。如果把函数以一等对象(first-class object) 的方式使用——例如拿来当别的函数的参数或返回值，然后适时地允许调用之，自然地就用到了所谓的回调。关键是“不限制”当作参数或返回值以后获得的对象被当作其它函数同等方式地使用。
这个时候，刻意需要理解回调的概念是不必要的，因为只有比较残废的缺乏一等函数的语言中，才会显得要用其它特性来弥补这种一等函数基本功能的缺失的重要性。
——说白了，大部分情况需要强调回调的概念，是因为在用其它特性实现一等函数作为变通。
而如果已经这样自然地用上了回调函数，反而不会（不需要）拿它当一回事儿，这就像把一个不是函数的一等对象当作参数或者返回值一样自然。
至于所谓异步如何如何，什么什么模式如何如何，与其说是回调给你的功能，倒不如说是健全的“函数”本来就该能够实现的东西。只不过只有残废版的函数能用的下，你需要借助其它特性（比如“函数指针”）来变通罢了。

没一个省心的，迟早得自己撸个。
暂时 Outlook 凑数。（老实说，光是备份本地数据缓存就极其不爽了，之前还有回滚 Windows 版本，大概因为这货在 %APPDATA% 里的 junction 的关系，把数据滚没了的……）

不需要 try 只需要 catch 是打算长什么样的？就是隐含了 expand 到 block，顺带不让用户选择要 catch 的范围？

非业内，不过这种问题最好别脱离业务背景。能来钱的地方，怎么混都跟技术积累根本上关系不大；通常你对雇主体现的价值仍然是你能够发挥出的应对问题的能耐（以及经验）。至于问自己想要如何……主要应该是看你兴趣。
我看到互联网拿出来鄙视的，至少就理论 CS 的角度来看几乎都是拿虎皮画大旗，凡是真能吹出点别人没有的东西的方案都只适合相当 specific 的场景，而具体业务以外基本都是落后几十年的（相对来讲）没什么技术含量的拾人牙慧的破烂——尤其是后端。
（前端自觉作死乱试错重新发明烂轮子，反倒偶尔敲捣几个恰巧同时理论上正确而且还算有用的踩坑经验出来，比起后端普遍理论和实践都歪得更多而靠偶然因素混出效果来的做法，某种意义上还是能让人服气一点。）

@zhuangzhuang1988 讲道理，这才是正常思路嘛。
技术上讲，要比较彻底地（让最终用户不被坑地）解决这个问题，提供 IDL 都不够用。不说这里实现的 bug 可能比编译器出问题更没法收场，就是都正确实现了，插件不守规矩出的问题很可能就无解，加上容忍不可信来源就更加没法收场了。
敢这样做方案的，要么极端地限制二进制接口（到插件不太有意义的程度），否则起码得自己发行包管理器和对应的版本库保证二进制版本可追溯。对开发用途来讲，还得集成 CI + devel pkg。
说到底这就是操作系统发行版的干活。以二进制插件兼容为荣的浏览器都普遍放弃了这个做法。
（……而想以开发者也不被坑地彻底解决这个问题，起码是要自己实现链接器限制某些特性滥用的。）

Ubuntu 用的第三方库，本来就没给你打算交叉编译来用。问题是你自己搞不到源码直接自己编译？
退一步讲，就这些库的节操……真用，跑个虚拟机搞个环境都比你搞交叉编译省事。

@SPACELAN 静态链接兼容性一样要看节操，谁给你保证更好的。
更没法变通才是真的。
另外 Win32 上嘛，静态库里糊个 main 进去还可能让链接器找不到入口……