@liuhouer OS X 确实是有骚操作的。
比如之前 OS X 钦点的编程平台 Objective-C + AppKit ，动态性是很强的。也就是说我拿到一个 OC 的 Cocoa App ，很简单就能还原出里面的很多符号，做 Hook ，对逆向比较友好。
Windows 钦点的平台 C/C++ + Win32 API ，东西编译出来之后再想逆就比较难搞。

iOS 和 Android 并非一个合适的对比，iOS 属于不完全开放的平台——并不体现在文件系统或者 App Store 之类上面，而是用户如果不花钱向苹果订阅开发者服务，就难以长期稳定地在 iOS 设备上运行自己的代码，也就是 iOS 不允许用户 program 自己的设备。从这一点上来说 iOS 设备更像智能家电，而非“智能“手机。
Mac 和 Android 不存在这种问题，iOS 从根本性质上就跟它们不一样。

当然现在苹果这边在搞 Swift + SwiftUI ，貌似静态的东西更多一些，而微软折腾 C# 很久了，可能现在情况不大一样（所以我限定在了 OS X ，而不是 macOS ）。
另一方面，类似系统换肤之类的事情，不论哪个系统，可能已经有十年没再出现在主流视野了。

我现在其实不想用什么“内存”之类的词，“存储”这个事情讲细很可怕：SRAM 缓存，同一 package 的 eDRAM/HBM ，普通的 DDR DRAM ，NVRAM ，NAND SSD ，HDD ，USB 存储，云端，磁带，软盘，这些一样么？

不如直接说好了是 LPDDR 几的“DRAM”，UFS 几的 “NAND”。

#10 @cxe2v 你有没有想过，被“误用”这件事情本身，也是一个新的故事呢？
（当然，本站最近流行的，以及其他地方可能搞过，正在进行或者将要搞的，试图教育大众的尝试，也是新的故事）

另外生命周期的问题最好是搞一个有各种 ctor 和 dtor 的类，这样看着清楚一点。

第一个，v1 = v2 时会把 v2 里的元素拷贝一份给 v1 ，所以你 v1 是可以用的
第二个，有两种可能，一是虽然 UB 了，但是并没出明显的错误。二是你遇到了 C 坑爹语法里的一个坑，你定义了一个名为 q1 ，类型为 shared_ptr<int>的变量，而非用 q1 初始化了一个匿名的 shared_ptr<int>值。由于你这个奇葩排版实在是难以判断，我怀疑你要是把整段程序都写出来没准还能看到什么 studio.h ，void 面函数之类的

@pursuer 语言设计者一般开始就会有如何实现的假设，这个假设会影响语言设计以及最初的实现，这些都和最关键的“设计目的”相关，之后才是生态，生态再反作用于语言设计和实现 ... 语言初始的设计是个种子，生态是从这个种子里面长出来的。这个方向大多数情况都被其初始实现也一般是设计者自己搞的实现也一般是至少在一开始最流行的实现钦定好了，后来的实现，尤其是能获得广泛应用的，一般都沿袭初始实现的模式。等到生态扩张到一定规模，再想改就难了。

比如 C++，它设计的目的就是加强 C ，里面那些 C 的东西放在虚拟机里面不好做也没必要，模板语言只会有编译时能确定的东西。当然有一些“生态”里面的人想把搞一个带虚拟机的 C++，结果搞出了 Java 和 C#，从 C++ 生态脱离了。C++ 还是原来那个 C++。
重要的不是编译器或者虚拟机，也不是具体的功能，而是为什么搞出这么一个新语言，它的核心目的和定位是什么，它存在的价值是什么，它有什么思考和沉淀 ...

后面也感觉不太对，比如 C/C++ 既有 Windows 生态也有 Linux 生态，很多 C++ 开源软件在 Linux 上也不会出现大量重复的情况。而专有软件倾向于无论哪个系统都要全部依赖打包在一块。Java 、Python 程序也可以做成类似大部分 Electron 应用的分发形式（如喷气脑子 IDE ，一些 Java 游戏等）。可见一个完善的生态并不会限制开发者在你说的依赖处理方面的选择。这个在不同语言之间的差异是比较小的，倒是和应用场景关联比较大。还是拿 C++ 来说，C++ 并不 care 你到底怎么分发软件，它只负责提供性能潜力和抽象能力，因为这是 C++ 的核心特征。

#17 @murmur 不敢苟同，在我看来，虽然现在新的老的各种语言很多，但是真正实用的静态类型编程语言，依然是一个未解决的问题。

这个“真正实用的静态类型编程语言”的意思是：跨平台，有基本的“现代”功能集，主要面向 native AOT 编译且运行时较轻量，支持多线程。

动态类型、有虚拟机的编程语言已经有 JavaScript 、Python 、Scheme 等成功典型了。
静态类型，有虚拟机的，C#，Java 及一票 JVM 语言也都不错。
TypeScript 算是中间的。这些领域的吃鸡已经基本完成了。

但是静态类型无虚拟机暂时还比较混乱。C 抽象能力太差，C++ 洞太多，Ada 、Pascal 、Fortran 、D 等要么凉了要么不温不火，Haskell 智商兼容性太差。上个十年这一波新语言可能得有一半，包括 Rust ，Swift ，Go ，Nim ，Vala 之类的都在试图解决这个问题。而其他很多新老语言，如 Kotlin ，Scala ，C# 甚至 TypeScript 也在探索这条路，现在吃鸡大赛暂时还没打完。

你举的这几个例子比较失败，AOT 编译+静态类型是 Flutter 核心卖点之一。Lua 是动态类型先踢出，TS 不完全是静态类型不适合 AOT 编译也踢出，C#虽然可以 AOT ，但是语言本身并不是针对这个设计的，削足适履可能还不如用 Dart 。在我看来，Dart 只是刚好 check 了上面所有的 box 的“经济适用语言”而已。

你举这些例子还不如问为啥不用自家的 Go 。我推测这涉及到另外一个问题，就是除非语言具备足够的元编程能力并且工具提供良好的支持，要做 GUI 框架，总是要其所依赖的编程语言本身配合加点功能更好。比如苹果专注做 GUI ，从 NeXT 算起的两代语言，Objective-C 和 Swift ，都为了 GUI 开发做了一些定制（当然跟你说苹果可能显得我大脑比较高级 ...），JavaScript 也有 JSX 之类的东西，GTK 也自己搞出个 Vala ，Qt 最奇葩搞出个 moc 。
那比较理想的情况就是，框架开发者能在一定程度上控制语言的发展。C#、Swift 之类的是别人的，没法控制，Go 已经做大了（可能还有内部的一些组织问题），看起来也不好控制，就拎出来个 Dart ，一边需要个工具语言，一边需要推广，一拍即合，皆大欢喜，双赢！

这个主题最大的问题不在“开发浏览器”那块，是在于标题 ... 这个不仅仅是个解析器的问题 ... 解析器只是第一步，最 tricky 的应该是布局引擎那块。JS 引擎应该是现成的。

@dragondove 其实自动麻将桌 Media and Entertainment 下面 Linux 软件不少 ... Maya ，Mudbox 和坟头草都已经三丈高的 XSI 都是，小的还有 MotionBuilder 和只支持 Linux 的 Flame 之类的。Adobe 非要说的话也有，毕竟现在 Substance 改名叫 Adobe Substance 了（狗头
不过上面大多是买的，不少本来一开始就是 UNIX 工作站软件。自动麻将桌传统的 AutoCAD ，3ds 从一开始就是 DOS 软件，后来 Revit ，Inventor 和 Fusion 360 也一脉相承了。
这个和 Mac 其实差不多，一边不少 VFX Studio 在用 Linux ，但是另一边 Linux 上的 CAD 到现在没个戏。

改变不了以上 Linux 软件和 #45 中列举的软件的开发者都不懂产品也不懂架构的事实（

讲真，就代码质量来说，暂时还没见过比一线开源项目平均值还高的商业项目 ...
都是屎山，五十步笑百步而已

不由得想起 Linux 社区一个老梗：很多年前慕尼黑政府搞了一个迁移到 Linux 的项目，虽然搞了好多年，但在那个“The Year of Linux Desktop”看起来无限遥远的年代（现在应该是近了点，不过看起来会长期处于无限接近“The Year of Linux Desktop”的一个状态，或者干脆叫“Linux Desktop 初级阶段”？），这个事情貌似当年也是被社区津津乐道引为 Linux 在终端的一个应用案例。
结果搞好没两年，微软说要把德国总部迁到慕尼黑，市长也换了，新市长说 Linux 不行，要换回 Windows ，又折腾好多年。最近又出新闻，说新的市议会决定支持使用开源代码（但好像并没有明确说是否会再换回 Linux ），同时的新闻还有 SH 州打算切 Linux （ Reddit 网友：“微软：在路上了在路上了”）。

@retrocode 我倒是感觉 QQ 机器人最近正在文艺复兴，GitHub 上不少乱七八糟的项目，再仔细翻的话闭源的也有不少搞的。

Linus 可能对潜水更有兴趣

> cli 的各种功能是堆出来的
不仅限于 Git ，可以参考下这个 https://danluu.com/cli-complexity The growth of command line options, 1979-Present

> 实际上，工具越出名，越底层，改进的空间越小。

其实我觉得抛开原 Git CLI 那一套东西，有没有一种可能，我是说，有没有一种可能，包装出适用于特定工作流的工具，无论是 CLI 还是 GUI 。可能没法很好兼容 GitHub 等现有工具，但是至少做到单独使用比较流畅。类似的想法楼上也有，但是我觉得目前大多数基于 Git 的工具，都还是需要对 Git 的底层原理有一定理解，最后导致多少还是不得不尝尝 Git CLI 的美味。如果只是针对特定工作流做，或许能把原理也给简化掉。

不要 assume“时代在进步”，很多东西不倒车已经是不错的了。
SSD 虽然快，但是不同 SSD 的速度也是参差不齐（特别是“便宜”的）。
软件就更别提了，放眼现在的主流文件系统，除了 APFS 之外，所有其他项目的底子都是上古时代的。APFS 倒是够“新”，所以 APFS 有个功能叫“Fast Directory Sizing”，可以直接从文件系统层获得文件夹的大小，不过就连这个好像也是需要手动启用，并且 Finder 自己也没有用上。
而且现在文件系统的痛点不是大文件，而是大量小文件。经过软件抽象后，SSD 把大量小文件操作的速度提升了 1-3 个数量级，但是还不够。我 du 了一下 home 目录下的几个大文件夹，大概需要的时间在 5s-30s 以内。Windows 下用 explorer 看 C:\Windows 文件夹属性，统计大小花了 2 分 15 秒，换了一台 Windows 需要大概 1 分钟。无论是十秒钟还是一分钟都不是 UI 上能接受的量级。当然这么巨大的文件夹是少数（虽然我每次打开 home 或者 C:\ 都会看到 ...），但是问题在于那么程序呐，就都不知道，自己就不可以预料，一个文件夹到底有多大，需要花多长时间，这是个 O(n) 而非 O(1) 的过程。
可以通过缓存把这个过程变成 O(1) 的，比如 Finder 会把算好的文件大小放到 .DS_Store 里面去，不过既然涉及缓存，就必然会涉及到缓存如何更新的问题，这已经被证明是计算机科学中两大最困难的问题之一。比如 Finder 就没有处理好（我也不指望它能处理好）——我现在能看到有很多里面有一堆文件的文件夹大小显示 "Zero byte"，但是这个功能依然是我认为 Finder 是最好的文件管理器之一的最重要原因之一。Finder 并不是唯一一个可以直接显示文件夹大小的本地文件管理器，KDE 套件的 Konqueror 也可以，这货保持了 KDE 的一贯作风，把这个功能藏在了设置深处，但是它是有限制的，如果目录嵌套超过一定的层级就不会显示，而这个阈值可以调整，这倒也是 KDE 的一贯作风。至于 Konqueror 有没有缓存就不清楚了。Konqueror 还有很多有趣的设计，比如和上古时期的 Windows 一样，把文件管理器和浏览器放在一块，它的“收藏夹”菜单（虽然现在貌似流行叫“书签”，但是作为从上古 Windows 玩过来的我还是更喜欢“收藏夹”）既可以放 HTTP URL ，也可以放本地文件夹。可惜这东西现在好像已经基本是被抛弃的状态。还有个比较勉强的是 Midnight Commander ，这货是个 TUI 界面，选中文件夹按 <C-Space> 会现场计算大小并显示在 size 那一列里，多选可以批量做，但是切出去这个信息就没了。

Konqueror 我倒是一般不会用，我日常用的还是 Finder 和 Dolphin ，对比之下发现 Finder 这个功能不仅 bug 多，还有额外的一些代价——比如在访问 HDD （包括使用 HDD 的 NAS ）时，由于 Finder 一直在试图统计文件夹大小（部分情况还会涉及到生成媒体预览图），而 HDD 现在作为仓库盘一般什么乱七八糟的东西都有，就会让 HDD 一直处于忙的状态，很吵，Dolphin 就十分安静。额外生成的 .DS_Store 文件也会有麻烦——做个 Git 仓库，打个压缩包之类的都会掺合进来（ OS X 有个开关可以禁止在网络磁盘上生成 .DS_Store ，但是这不解决根本问题）。另外如果是个移动设备，统计文件夹大小占用的额外资源可能会增大耗电量。从这些角度来说，认为“始终统计文件夹大小”在现行软件栈中有百利而无一害的大概跟喜欢用 Electron 的是一种生物，不是蠢就是坏。

从另一个角度来说，统计文件夹大小真的是那么常用的需求么？对于服务器或者大多数命令行场景来说，一般不是，服务器要想干这个有 du 。如果按照现有体系，O(n) 遍历统计，就意味着你随手敲一个 ls ，就有一定机率需要等 10-20 秒，盲盒在 70 年代被提早发明了！如果把文件夹大小存在文件系统里，那每一次 IO 操作都会附带更新这个信息的开销，而如果这个信息只是偶尔使用，很明显不值得。所以为服务器设计的软件肯定不会考虑这个问题。这个东西在消费者那可能用处稍微多一点，但也不是那么多。要想看谁占磁盘多有 QDirStat 这样的专门软件，并不一定非要文件管理器或文件系统来兼职。一个好用的磁盘占用分析工具实现上可能会涉及到一些优化技巧，不是简单的递归遍历能解决的。作为一个 Linux 用户，从各方面平衡的角度来说，我还是更偏向于 Konqueror 那样的做法，成本大的功能默认不打开，打开之后可以自定义。

再往远处说，“文件”这个抽象，过时了！淘汰了！（ https://zhihu.com/question/472997775 ）上面的讨论已经很清楚了，“文件系统”以及 OS 的文件操作 API ，既需要处理少量大文件也需要处理大量小文件，既包含 sysfs ，也包含 RAM Disk ，Optane ，SSD ，还包含 HDD ，网络，和 5.25 寸软盘。而现在一般用户还有多少机会直接和“文件”打交道呢？ iOS 从发布时就直接隔开了不同 App 的文件存储，用户在笔记软件里的“笔记”也是直接在相关的软件里面访问的，Office 现在也在往云端发展，小而美倒是好像能把聊天记录备份成文件，不过也不能直接看，而且相信我如果小而美有个网盘业务的话，大概不会允许你直接往本地备份。
抽象总是有代价的，专门的需求就需要抛开通用的抽象，用专用的工具解决，比如做 Web 服务器用的是数据库，不是直接把数据 write 到文件里面。

当然这是本地的问题，至于为啥云端的东西不给你看，那答案倒是很简单，因为这些产品和“小而美”的设计思路，精神内核都是高度一致的，都是把用户当 ...

比起这个，我觉得给 Finder 和 Explorer 加上分屏功能倒是更有用。

函数不需要复制啊，一个东西需要区分“复制”和“引用”，是因为这东西可以修改，或者需要管理内存。函数没法修改，内存管理 JS 帮你干了，就不需要复制了。

A 站这评测早就说了，得有一个半月了 https://www.anandtech.com/show/17024/apple-m1-max-performance-review/2

TIL star-history.com