@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

想买就买吧，除非经济负担很大，如果能承受得了那就买。我第一台 MacBook 是十年前刚上大学的时候买的，用父母给的钱加上自己攒的和从朋友那借的一点（不推荐），找一个人从香港带回来的货。发货那几天真的是梦里都是触控板的手感，到了之后也很喜欢，陪伴了我七八年。现在不拮据了，MacBook 想买就能买得起，但不会有那个时候的快乐了。

我的理论是：

1. 如果你现在没有买，那你后面还会卡在这个问题上（我假设你已经有这个想法一段时间了，如果是两三天头脑发热那可以再缓缓），你现在已经有 PC 了还好，如果在纠结买 PC 还是买 Mac ，其实选 PC 后面再买 Mac 总成本会更高；

2. 如果你现在买了 Mac ，然后发现自己不喜欢，那用一段时间出二手，只要自己不是官网原价买的，考虑到 Mac 的保值率，不会亏很多，换来的是以后很长一段时间你都不会对 Mac 有任何想法了，所以这笔亏的钱也是得出的；

3. 如果你现在买了 Mac ，然后发现自己很喜欢，这是最好的情况。梨是什么味道自己尝了才知道，有些人就是喜欢 Mac ，有些人就是讨厌，说不清楚的。

4. 说个暴论：计算机专业，如果自己遇到 macOS handle 不了的情况还不知道怎么弄的话，趁早转专业吧，这专业不适合你。

我大学的时候遇到类似情况，解决方法包括：去学校机房、虚拟机、找朋友借一下应急（如果是组队项目，其实很顺理成章，把别人那份 work 包下来，别人还会感谢你）。如果真的需要一个持续的 PC 环境，那稍微了解一下后，靠捡垃圾、二手可以以非常低廉的价格搞到一个能用的。

什么？你说要高性能显卡？谁会要求每个学生自带环境的，遇到这种老师早点跑路吧。什么？这么麻烦为啥还要买 Mac ？重新读一遍上面的 2.

Swift 理论上支持 Windows ，但优先级估计没有 Linux 高，有空可以自己折腾一下。Linux 对 Swift 工具链支持相对好一些，各种 Swift on Server 的库也能跑，一些本来只在苹果平台可用的库（比如 Combine 、CryptoKit ）只要和 GUI 没关的，都被苹果或第三方移植了。

如果你指的是用 Swift 写 macOS 原生 API 的界面，那 Windows 和 Linux 还真不行。（有人给 Swift 做了面向其他 GUI 框架，比如 Win32 或者 GTK 的 Binding ，但热度不高）

话说像这种代理软件，如果不做 GUI ，不支持所有协议，自己对网络 API 熟悉点写起来应该挺快的？

这类产品的溢价我称之为：第二类苹果税。

第一类苹果税是直接流进苹果钱包的，比如 App Store 抽成、MFi 成本、硬盘内存的高溢价等。

第二类苹果税就是那些并不是由苹果赚走，但因为这类商品在 PC/Android 这边少需求或者没需求，所以体现在更高成本的那部分溢价，比如小尺寸 4K 显示器、Thunderbolt 存储扩展方案、macOS 键位键盘等。

解决方案：下个 SwitchResX 然后设置成某个带 HiDPI 的分辨率

@zwpaper
gnome 可以设置文本框用 emacs 快捷键的，但是 Linux 基本没啥好的用 Mac 键位的方法