开源世界是讲投入回报的。Firefox 再怎么不行也不可能短时间搞出个新引擎把它比下去。综合来看 Firefox 就是对 Linux 世界最友好的。所以哪个桌面环境会把 Gecko 当作 WebView 呢？

@marc2017
iOS 和 iPadOS 只是因为屏幕大小和电话属性所以多了/少了几个系统功能，技术上是一样的，Xcode 里写代码也都是 iOS ，混用不会引发什么误解。过度区分甚至算掉入某种宣传陷阱，好像 iOS 和 iPadOS 的差别真有 iOS 和 macOS 一样大了一样

iPhone 的内存就是卡着相机的需求来的。如果某代相机对内存的需求大幅提升，iPhone 才会提高内存容量。iPhone 的内存比起 Mac 还是好不少，iPhone 4G RAM 虽然杀后台但起码能用，Mac 8G 你送我我都真不想用。

现在的问题是 iPad 已经对标 Mac 上到 8G 、16G 内存了，体验过 16G RAM 的 iOS 再回头看 iPhone 那是个什么玩意……

最新的 JB 更新更改了 macOS 下全屏的行为，我没见过其他软件全屏状态里还显示红绿灯的，看着特别奇怪。哪怕 Firefox 这个全屏隐藏不了标签栏的都没有红绿灯，不知道有没有违背苹果的 HIG

因为一些人认为聊天这件事应该是异步的，另一些人认为聊天应该是同步的。问在的目的就是希望能够立刻得到回复。

人年龄大了以后沟通能力会「钝化」。上中学和刚上大学的时候能和班上的同学没任何目的地瞎聊，明明不熟的有事没事发条消息过去也不怕，现在回过头想太尴尬了。而且成年人三句不离利益，很难有这种纯粹的聊天了

XXX 之父有营销的含义，但在程序员圈子里本来就是个经常被嘲讽的梗。最有名的应该是「谭浩强 C 语言之父」，以前有个同学姓谭，我们那会管他叫「谭浩强之父」🤣

《阮一峰为什么是神》

如果网站只给自己访问，或者只给少数信任的人频繁访问，干脆自己签个 ip 证书换个端口还方便点

@manasheep
我以为是质量问题或者某个平台有坑，点进去发现这个视频不是老早论坛里就有人吵过了么。鉴于本站大部分用户都或多或少用过 Windows 之外的系统，我认为不能和 B 友同等看待

除非遇到 intel 转 m1 这种情况，大多数时候多用一年省的钱肯定是大于晚出一年亏的钱的。这时候就看老设备的体验还行不行了，如果是 iPad Pro 2018 这种产品，那留着肯定也不亏。

协程和用户态线程是不同的东西，只是 go 利用特殊设计在后者实现了前者的要达到的效果。Swift 的并发支持也有点异曲同工之妙

要留存文化火种，建议多到墙外发言，把国内流行的梗搬运到墙外。现在已经有这个趋势了

我之前就有类似的想法：很多软件许可证、密钥或者加密货币助记符之类的都是一串 hex 或者英文单词需要用户记住，为什么不改成 emoji ，emoji 量大还能减少点长度

我觉得时间安排是不能把利用率假设得很高的，降低预期，这样下班回来做一点事情也会很有成就感。本来就算六点下班，吃完饭回家再折腾折腾怎么也要七点了，这个时间容易犯困，而且本来就是工作一天后精力不够充足的时间，精神上还有种上班没玩手机下班了想找补回来的心态，效率不可能高。

人毕竟不是机器人，没利用好时间你可以理解为是在休息。不知道你有没有过熬夜打游戏、熬夜玩手机和熬夜干活集中精力，同样熬夜，身体的感觉完全不一样。所以即使回家什么都没做，对身体也比加班要强。

有时候有感兴趣的项目，可能下班回家后能一写写几个小时，但这种情况是爆发性的，天天如此会受不了。你不如重新计划一下自己的「目标」。

C++的成功来自于它在 C 的基础上提供了抽象能力，而抽象能力是开发大型软件所必需的。C 的成功自不必说。C++走了一条和 C 源码级兼容（除开某些语言细节上的差别）的道路（很多早期设计理念可以参考《 C++语言的设计与演化》这本书，讲得很好）。兼容性对 C++的成功至关重要。一开始我还不太能理解，直到后来遇见了 Objective-C 这个语言，它也可以和 C 源码级对接，苹果选择它作为平台开发语言和 macOS （前身是 NeXTSTEP ）基于 UNIX 一样，可以充分利用已有的技术，是相当正确的决策。

这种兼容性到现在带来了很多弊端，比如很多默认设定你就不能改，想要更 modern 就得自己额外写一点东西。但总的来说直到现在 C++和 C 的兼容都是利大于弊的，没有这层兼容最起码要和其他语言互操作就很麻烦（即使在同一个平台上 C++也没有统一的 ABI ）。所以现代 C++的理念发展到现在，很多是在保留 C 遗产的同时整一套新语法，比如 C++14 的统一初始化、C++17 的结构化绑定和 C++20 的模块。C++标准委员会主席 Herb Sutter 搞了个叫 Cpp2 的东西，即推一套彻底新但是概念上和 C++相似的语法，然后通过一个预处理器编译到 C++，和当年最早的 C++到 C 转译器一样。这玩意本身当然不可能成为一个真正流行的新语言，但它更像一个 C++发展的试验场，由此也能看出所谓现代 C++的终极目标是在不放弃旧代码库的同时打造出一个先进的新语言。

很多人可能瞧不起旧有的 C++代码库，觉得那都是迟早要进历史垃圾堆的玩意。然而连 Fortran 到今天都活得好好的，更别说更流行、吃到更多版本红利的 C++了。商业 C++代码我们不清楚，就看 LLVM 、GCC 、Chromium 这些巨无霸，它们可不是什么老旧代码，时刻都在演进。Google 想恶心 C++也没法全抛弃，只能搞了个类似前面说的 Cpp2 一样的 Carbon ，然后曰你们新项目都用 Rust 来写吧。Mozilla 算是这个星球上最纯正的 Rust 粉了吧？他们自己都没有太多用 Rust 重写 Firefox 里已有 C++代码的打算。所以 Clang 要往 C++塞生命周期标记，不是脱裤子放屁强行和 Rust 对标，而是非常有意义的现实需求。

如果单纯把 C++当作一个既有代码库里才会用的语言，那 C++现在的状态其实还算健康。反正这些项目都已经定型，也不需要什么包管理器，CMake 本身就能当脚本写，实在不行拿 Python 出来承担构建工具的活也可以。但问题是：有多少新项目会使用 C++？

这个问题可以分为两个子问题：第一，有哪些和 C++定位不同的语言取代了以前该用 C++写的项目；第二，有多少和 C++定位相似的语言取代了 C++的位置。第一个问题，在 Web 领域那显然是 Java 和若干脚本语言，在 GUI 领域则是 Java 、C#和 HTML5 ，中间件是 Java 和 Go. 第二个问题，先简单定义一下什么叫和 C++对标，就是有不错的抽象能力，有强类型系统，没有引用计数之外的垃圾回收，那 Rust 和 Swift 都算比较出名的竞争者，Swift 由于各种和 ObjC 兼容的负担以及苹果在自身生态之外确实没有什么想法，那就只有 Rust 了。

目前看来 Rust 的进展很快，也搞出了一批「用 Rust 重写性能提升 xx 倍」的大新闻。我个人对这种营销不太感冒，但不得不承认它确实很有效，连本站都有很多人一看用 Rust 写的项目/学 Rust 就牛 X ，看到 C++写/学 C++就啊真老土。Rust 的地位在我看来离真正稳固还有距离（我 2015 年发 1.0 的时候第一次了解到这个语言，发展到今天算是超出预期，但比不了 Go 那种爆炸式流行），不过它确实做对了一些事：(1) 很早就提供了统一的包管理器和分发平台，还有 rustup 这种工具链管理器；(2) 把最佳实践落实到工具链层面；(3) 在保持基本兼容性的前提下，语言演进速度很快，RFC 通过后可以立刻实现，过几个版本就稳定下来。我和一些工作上用 Rust 的朋友聊过，惊奇地发现他们居然每天拉 nightly 的编译器来干活，这在 C++世界简直不敢想象。

个人觉得，C++的优势：大量已有代码库，各种平台兼容性，社区体量，IDE 支持，基于模板元编程的表达能力；
劣势：语言演进相对慢（求稳是好的，但可以编译器先实现再慢慢改，之前 module 和 concept 就是这样，可能还是因为编译器太复杂，而且用户对新特性也不热情，恶性循环），编译期反射能力欠缺，工具链不够便利（ CMake 只能说能用，新世纪 20 年代了你给我说一个命令式构建工具有资格叫 modern ？ xmake 也比它强。还没有被广泛使用的包管理器，交叉编译也不方便），很多语言之外的东西比较碎片化没有统一

讨论个 Mac mini 的模具都要人身攻击一手过分，anti2ex 果真逆天

@zhouquanbest
库克精着呢，有这技术也未必会放出来。M2 最大 24G ，M2 Max 最大 96G ，再根据 M1 系推算 M2 Pro 应该最大能支持 48G ，但就是不给做出来，想要超过 32G 的必须上 Max