@tozp ……GateHub 吃 KYC 账户动不了求破。。。

@Messiv2 说起来为什么你会拿微信这种 IM 界倒退扛把子的玩意儿当代表呢？

要知道就是只算 tx 自家产品，功能上微信基本也是被资格更老的 QQ 打出翔来的……

是不是你对倒退的相性特别出色？

@Messiv2 那大概说明手机是一种倒退。

不少手机用户和产品也是倒退。

比如华为之前截图 PNG 的，几个人花粉论坛嚷嚷了大半年要 JPG，然后还就真改成 JPG 了，呵呵呵……（给个选项会死？）

嘛，JPG 什么时候死呢？

现在买基本不会比放银行好。
不过你也没说放银行是啥。活期和净值型理财能一样么。
最关键的是，这 50W 谁的？你的部分自负盈亏，你爸的你就别多嘴了。

智能指针不止是 std 给你的那坨。

没有所有权的指针语义上更清楚的是 observer_ptr （如果不需要 nullable，那直接引用，包括 & 、&& 或者 std::reference_wrapper 或者其它什么类似物）。这种做法唯一的缺陷就是罗嗦，但这是语言设计本来的问题——谁叫内建指针这种责任不明确的垃圾占用了 * 这样的更简洁的语法呢（即便 * 这种语法本来就很不咋地）？注意，如果要求是像样的而不是容易让实现偷懒的设计，原则上混淆使用目的的内建指针就不应该直接在高级语言中提供： https://github.com/FrankHB/pl-docs/blob/master/zh-CN/why-is-pointer-awful.md 。
内建的指针因为兼容包袱永远不可能更清楚，所以和 LZ 的提法相反，就是应该能禁用就禁用，而体现不得不用和可以被其它类型取代时的区别。事实上：根本意义上只有一种情况才必须使用内建的指针——互操作，例如内联汇编需要依赖二进制兼容，或者 new 这种从核心语言特性钦定返回内建指针的情形的变通（本质上，返回内建指针仍然是个目无所有权的糟粕设计，仅仅因为 T* 是内建语法就凌驾于去任意地复用而不是提供特设的 new_ptr<T> 或者干脆直接返回现代意义的 unique_ptr<T> ，这种选择根本没什么逻辑性，而且是个后患无穷的做法；只不过当年 C++ 还没模板也没 move copy-initialization，这种垃圾设计就当历史包袱忍了算了）。使用内建指针根本不能区分不得不用内建指针和允许使用 observer_ptr 的情形，仍然削弱了目的性。
题外话，BS 是反对 observer_ptr 的： http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1408r0.pdf 。不过，根本上他的理由站不住脚，一部分就是上面的原因（另一部分问题是关于语言特性历史包袱的理解和 WG21 整体对核心语言设计演进方向控制上的普遍无能）。

有所有权的情形在 unique_ptr 之前首先考虑直接传值。（至少还得清楚没法表达 __restrict 的情形下没事用指针 /引用永远是被坑的。）

shared_from_this 有的坑是因为 weak_ptr 被滥用：
https://stackoverflow.com/questions/39653239

穿痛衣，，，

gitconfig 配置 [alias] ，再不行调用脚本。

@mcfog 你所谓好不好，是看应用场景而定的。这本身没什么问题：大部分人用某个语言解决配置问题，就只是把配置当 DSL 的代码来用。这种情况的前提是，别人替你把资源准备好了，告诉你足够靠谱，只管用就行。
但是要考虑更一般的情形就不是这么一回事了。没什么 DSL 能 hold 住各种不同的需求，整体上要造不同 DSL 的轮子方案数量都会爆炸。还可能有一坨方案的实现都根本不值得信任，搞不好需要自己实现整个“生态”的时候。最极端的情况下，编程语言我都需要自己造轮子，一个只能用于配置的 DSL ？写 spec 和实现都就是增加工作量。
考虑一下 JSON 的流行，本身就有这个背景。JavaScript 的设计是否干净得配得上被当成一个通用程序语言不说，好歹很多人就是拿它当通用语言来用的。JSON 作为 JavaScript 的缩水版，并不需要很多单独的设计，只要附加一些约定一个 spec 就出来了。这里 JavaScript + JSON 就显然比 JavaScript + TOML 或者其它什么别的省事。考虑实现，JavaScript 和 JSON 本身语法非常接近，所以很多设施都能够方便地复用。这进一步形成正反馈，让用户有很多途径找到可用的使用的 JSON 的解决方案。这里，有个足够流行的爹（ JavaScript ）就是 JSON 先天强势的主要理由，并不需要 JSON 自己的设计就有多“好”。（当然，JSON 的设计如果烂到让人受不了那肯定也是会在流行上减分的，但至少现在没到这个地步。）
相比之下，TOML 并没那么个好爹。TOML 本身的设计，溯源起来基本也就反映了 .INI ，并没什么很抓人眼球的创新。容易手写和不太难阅读是它的优势，但也仅止于此，能达到这个水平的其它的备胎多得是。要说包装结构化数据使其便于被可编程地处理，连 JSON 其实都打不过，所以它也就只能作为配置 DSL 来生存。TOML 的流行（如果算流行的话）主要是近些年 Cargo 之类的项目实际被广泛使用——也并不是因为它的设计有先进，只是恰好在这类项目中被人认为足够合适而已——这至少需要偶然到接触到它的人找不到其它更好的方案（挺难的）。尽管如此，仅在手写配置这个领域中想跟 JSON 竞争流行性，仍然是想多了。（手写 JSON 起码还没像 XML 那么容易烦躁到忍不了。）
考虑到 DSL 脱离具体领域无法互相比较，真正凭自己的设计算得上“好”的格式就不可能只能当 DSL。这部分其实 JSON 也不太够格，因为它的爹仍然有很大的领域局限性，脱离群众基础没什么现成的解决方案想自己从头造，一样分分钟缩卵。考虑通用性，这里有候选资格的大概只有 XML 和 S-expression，两者至少技术上都足够作为一系列通用编程语言的语法基础，也有不止一个例子。不过前者的祖辈(SGML) 历史包袱实在太混乱了，也没发展出个能把事情做干净的直系长辈和儿子（基于 XML 的编程语言实用上几乎全止步于 DSL ）；后者的历史太乱，到处是精神祖宗和孙子，然而就没什么直接标准化成功的方案（最像样的可能还是跟 XML 杂交的）。所以你要好的就自己搞自己的生态，要流行就别多想了。

@mcfog 关于你所谓的对数据交换的主要场景的理解，基本是不靠谱的。
任何足够成功的二进制中立的语言中间表示，特别是捆绑了标准内部和外部表示的方案，都算是你的理解的反例，如 LLVM IR 和 FASL(Lispwork's Fast Load format) 。而没有标准内部表示但比较容易实现的更通用的格式，如 XML 和 S-expression，也可以构成反例。
从实现功能上来讲，serialize 比起 marshall 来讲基本是伪需求。造成 serialize 算是个事儿的历史原因主要是，使用 ALGOL-like 这样的传统命令式语言的用户很少能想清楚先天就能 serialize 的格式该怎么设计，历史上一路上都在从实现开始试错而不会去先排除根本困难，所以传统上才会过分强调这个问题；然而对成熟的、一开始搞清楚什么应该是从被交换的数据里剔除出去的方案，这里根本就不应该有什么原则难度。Marshall 才真正涉及一些和结构以及具体目标语言的语义相关的麻烦事。
配置管理跟数据交换来讲，与其说是非常不一样，不如说是根本不算是应该在一个层次上实现支持的功能。配置管理是更高层的应用。（和数据交换同级别的应用是直接的可编程性，但这在非同像性的(homoiconic) 语言的时候基本没什么意义。）配置管理的基本表达就是可编程的数据，它也可以被交换；反过来可交换的数据就不一定需要能被可交换的外部格式表达。所以这个问题的结论上我倒是没什么根本不同的意见——LZ 的设计基本意义上不大。
不过 TOML 这类 DSL 还是算了吧，随便都能糊，没人用就没人权。

@janus77 这里看上去一方面是改的人太菜，一方面也是做 review 的人菜，没搞清楚第一时间把整个项目的公共配置恢复到正常可用的（不会动不动就累积冲突的）状态。
协作 review 代码的职责不只是为了验证代码的实现情况，更重要的是了解当前别人的工作情况并协调工作进度保证不会对项目的全局目标引起灾难性后果——不 review 的情况下只要作者自己靠谱前者的问题还可能不大，而后者……冲突一频繁整个项目的进度可能就完蛋了。
还可能是因为负责人太氵，根本就没安排资源去做配置管理，没让人搞清楚只允许改哪些地方……当然，对过大的、沟通路径太多的项目，使用权限管理不够强的 VCS （如 git 这种一开始就只考虑 bazaar model 项目协作的）时，可能加物理分隔（分 repo/submodule ）来强制更可靠一点。

@noobcoder1 在 feature branch 上每天先 pull 是典型的没约定职责清楚边界的错误姿势。
正常的做法是维护 feature branch 的人员不需要同时关心 merge 足够大的 milestone 以外的版本，要 merge 也是从 feature branch 往 dev 由专人负责，否则根本就没开 feature branch 的意义，还用毛线 DVCS。

你自己的 branch 难道不是你做主？不给 force push ？
只要你用的 DVCS，你就应该有底气你的工作以你为准。

网页在 UI 上还是太残了。“页面”的概念本来就不是为了交互式程序而产生的，以“动态”页面代替 GUI 程序交互的馊主意是之后补上去的，其流行也相当偶然。
即便只是考虑呈现可供扩展交互的静态内容的这个功能，现行的网页底层的超文本系统也比不过更早但因为某些（更偶然的）因素不够流行的设计，例如 Project Xanadu。
更麻烦的还是作为支撑交互可编程性的事实标准过于死板，特别是 ECMAScript 一家独大的问题（且不说 ES 本身有多烂）。WebAssembly 会逐渐改善这点，但不提供 AST 之后的设计已经无力使这部分运行时的工作直接演进了。以后会有不得不有更长的共存期。在强调 AOT 翻译的实现趋势下，交互使用的语言层次上提供的动态性很可能会被削弱，使动态页面为基础的界面进一步丧失和大部分其它 GUI 系统相比的仅存的可编程性优势。
AR 只是当前人机交互技术的水平扩展，并不能直接改善现有系统的缺陷，也不能有效地取代现有系统的典型应用。不管对页面还是非页面为基础的 GUI 系统，它的影响整体上是有限和相仿的。有没有 AR 并不大可能会导致现有交互程序的实现演进方向有实质区别。
综上，正常发展的情况下，现在意义下的网页技术上各种意义上都必须死，只是因为尾大不掉的习惯和兼容性包袱，会非常慢罢了。最终，不是浏览器干掉其它 agent 替你干任何事，是浏览器被其它更一般的客户端技术取代而重新融合，绕了一圈弯路而已。目前这样的一般客户端的公共实现中一部分是依赖 ES 运行时的，以后 ES 要是因为自身包袱等原因衰弱，具体线路就难说了，但是大的方向仍然不会变。
至于 LZ 说的网站形态不同实际上是另一回事。只要有需求，其存在性就不会有根本上的变化，只是会改换形式继续存在。