话说 Steam 虽然是 CEF ，用起来简直不是 Electron 胜似 Electron

@Buges 网站不错

是的，每年都可以庆祝"the year of Linux desktop"

很有意思的是，造成 C# 在特定领域不如 Java 受欢迎的最重要的，众所周知的那个原因，也亲自指挥、亲自部署了 TypeScript 的推广。
而 Java 这边是无法想像这种事情的。Java 这边也有一个“原因”，也要出新东西，但是貌似依然是要收费的？

Java 这个路径的问题本来不是什么大问题，但是实际对一部分人（主要是不用 IDE 的人，或者会用 IDE 的但是暂时没有用 IDE 的人）造成了 ergonomics 的麻烦

比如 GitHub 上面，打开一个 Java 项目，想简单看下源码要点 N 多次，这还是 GitHub 也“优化”了文件夹嵌套的情况下
就算我 clone 下来，直接用 shell 访问也要敲 N 多次键盘（还不说 clone 本来就多一步）
这些情况都可以装插件来缓解，但是在一个比较简单，插件比较少的环境中，这就成为了实际的问题。
一些其他生态中，很大一部分开发者就属于这种情况，那么 Java ，或者 Java 生态对于他们来说就是“麻烦”的。你不得不承认如果没有“专门优化”，处理文件比处理文本要麻烦十倍。

这不是说 GitHub ，shell 或者其他生态做得多“好”，实际上屎的东西很多。Java 世界做出了全面偏向 IDE 的选择，是有利于隔离外面这些屎的。（至于 Java 自己一堆历史包袱和生态内部问题搞出另外一大坨屎那是另一个问题）
但是问题在于某些 Java 开发者的心态——既然自己决定了主动与其他人隔离，就不要在意其他人的想法。但是某些 Java 用户不仅没有这个觉悟，还振振有词“Java 适合做带项目，你看我们的带项目多牛逼”

问题是为了做“带项目”，就一定要抛弃“小项目”么？我认为这就是 Java （或其生态）在不欢迎它的群体眼中的最大问题。一个旁例是 C#，C# 在语言本身的风评上总体比 Java 好（好像越来越齁是一个问题），生态上则主要集中在那个众所周知的问题上面。C# 也能做带项目，这些带项目中一样各种设计模式啰哩啰嗦，一样嵌套一堆文件夹，但是 C# 也有很多小一点的项目，GitHub 上高 star 的 C# 项目中并不难找到文件夹嵌套和其他语言差不多一个水平，目录结构非常简洁的项目，大概和 Swift 项目的感觉差不多吧。而这并没有影响 C# 做带项目。

我的观察是这种现象与项目的 domain 是强相关的，某些领域的项目做得就很 Java ，某些领域就不那么 Java 。所以 Java 这些特点可能与此也有点关系。

ergonomics 的另一个例子是 ... TypeScript 。可以说 TypeScript 设计上是想要把 JavaScript 往 C# 的方向扭（毕竟这俩同源，虽然最近好像没绷住变成了 Scala :P ），有一些 TypeScript 项目也出现了 “Java 味”的雏形（暂且不用“重”这种定义模糊的词，我们就用 Java 来定义 Java 和“不知道哪个时代的 Java 特色编程思想”）。但是人们讨论 TypeScript 时，好像主要是在讨论它的 Scala/C++/Haskell ... 味，而不是“Java 味”，这一方面当然是因为很多人本来就对 JavaScript 有更多的“Java 味”的需求，另一方面就是 TypeScript 的 ergonomics 做得不错——不仅是不错，而且可以说几乎就是 Java 的另一个极端。

TypeScript 解决问题的方式很巧妙，考虑一个问题：TypeScript 的 killer app 是什么？ TypeScript 的 Rails ，Docker/K8s ，Flutter 是什么？
GitHub 的数据告诉你是 VSCode： https://github.com/search?p=1&q=stars%3A%3E1000+language%3Atypescript&type=Repositories （前两个是 Markdown 项目）
这就很有意思了，因为 VSCode 这个项目本身是 TypeScript 开发的，但是领导核心是 Eclipse 正统，代码也挺 C#，内置了（非常不错的，“原生”级别的） TypeScript 支持。和 Eclipse ，IntelliJ 一样，VSCode 不仅仅可以用于 TypeScript ，并且这部分人还不少——VSCode 官方插件市场里面，Python 、C++、C# 都买了热搜（讽刺的是往后一点就能看到 Java 的热搜），后面还有 Go ，PHP ，Dart ...
暂时无法对比这些语言和 TypeScript 的数据，因为 TypeScript 的支持是 VSCode 内置的，内置的，置的，的 ...
反过来想，就是这些语言的用户，都是 TypeScript 的潜在用户！

我个人主力用 VSCode ，写 C++、C#，OCaml ，Python ，当然还有 TypeScript/JavaScript 。JetBrains 做了 Rust 的 IDE ，但是像 Haskell 这种不可能有人给做正经 IDE 的语言，也把支持 VSCode 和 LSP 作为第一优先级，OCaml 官方教程给新手首推的就是 VSCode 。这部分长尾，VSCode 也全吃下了。
虽然 Electron 在资源占用方面也很“重”，但是反正我写其他语言也要装这玩意，从开发其他语言的 VSCode 用户，转到 TypeScript 开发者，在 IDE 方面没有 overhead ，也就是装个 Node.js 和 npm 的事儿。
这就是另一点了——JavaScript 从小做起，人家做小工具也不差，所以我装个 Node.js 跑个小工具也不亏。
赢麻了。

@secondwtq s/狠，真 /狠，原来是因为都去搞开源了，真

这些大公司以前看上去很牛逼，实际上根本就不懂产品也不懂架构，这次算是揭了老底了，怪不得最近股价跌得这么狠，真是活该。

中央已经钦定了：
https://www.twitch.tv/curlhacker

内存占用和 JIT 、AOT 是没关系的，主要是 Tracing GC 的问题。Tracing GC 就意味着任一时刻内存中必然有一部分数据是“无用”的，造成内存空间的“浪费”。
其他 Tracing GC 的语言也一样，并且 GC 调优有时候还需要用更多的“无用”内存占用换取 GC 更少触发。
其实不用 Tracing GC 也会有其他问题，比如用了对象池 /内存池。在这些情况下，内核看到的内存占用其实都不能代表应用程序的“真实”内存占用，但是这些“没用”的内存又确确实实被占着。

永硕 E 盘 ... 楼主几岁了？

我用 Firefox 有两个理由：
1. Tree Style Tab
2. 之所以要用 Tree Style Tab 是因为我用 Tab 替代了 Reading List ... 而根据个人测试结果，当 Tab 很多的时候 Firefox 的资源占用是有优势的——至少对于简单页面，Chrome 平均每个新页面的边际内存占用可以达到 Firefox 的 up to 2.5 倍。复杂页面（ 包括 Google 自家的一些页面）也不输 Chrome 。另外 Firefox 允许调整 content process 的数目，虽然这个功能似乎在新版本里被隐藏了（实际上不仅 content process ，其他类型的进程也可以调整，比如设置 0 个扩展进程那所有的扩展都罢工了 ...），我觉得浏览器的多进程隔离仅在少数情况下是必要的——为什么要把我的 10 个 V2EX Tab 隔离起来？
但是 Firefox 自己这个壳儿的内存占用貌似很高，所以如果 Tab 量不多的话是没有优势的。

楼主的回复其实没有必要看，楼主纯粹就是黑果用着不太有安全感然后拿着锤子到处找钉子而已。

奉劝黑果用户，尤其是至少会上 V 站的黑果用户，尽早开始学习 Python 、Golang 、Rust 等先进技术，不要再留恋于别人剩的汤，而是自己做饭自己吃。

@stoneabc 虽然我也很想对如此基础的常识缺乏的现象发表一些感想
不过转念一想，显卡厂商如此宣传的 GPU ，有多少到了“gamers”手上呢？
所以还是算了 8...

@ShadowPower 讲真，拿 Path Tracer 测试 Apple GPU 和 Turing 之后的 NVIDIA GPU 和用 ProRes 编码测试是一个性质 ... 虽然 M1 成绩是不太好看，但是把 OptiX 拿掉也不至于得出“M1 Ultra 在这方面的性能只有不到笔记本版本的 RTX3060 一半”的结论

最大的“坑”是你自己的需求。消费就是把你自己的需求和市面上各种产品的 pros & cons 匹配的过程，如果你连需求都搞不清那自然是坑了。你这个主题的问题其实就是没说清楚“写写代码”的需求到底是什么，搞了好几楼才稍微清楚点。

我其实还想说发错了地方，但是鉴于绝大多数社区的用户在讨论硬件问题时都直接 assume 了“作为终端使用”的大前提。另外作为同用远程 VSCode 写 C++的，我可以告诉你本站大多数用户都不写 C++，所以他们会认为最“重”的 workload 就是给脑子充气，也没有开个静态链接就直接把系统搞到 thrashing 的经历。但是我想了半天实在想不出还有什么更好的地方可以去。

从需求的角度来说，什么核数、主频、IPC ，都不能直接地和你的需求建立起联系来。最实际的标准就是看哪个播放 Are you OK 的音质更好 ... 说错了，是跑分。比如打开 openbenchmarking.org ，有一定概率你会在首页直接刷到这个 AMD Ryzen 5 5600X 6-Core vs. 2 x Intel Xeon E5-2683 v4 vs. AMD Ryzen 9 5900X 12-Core https://openbenchmarking.org/vs/Processor/AMD+Ryzen+5+5600X+6-Core,2+x+Intel+Xeon+E5-2683+v4,AMD+Ryzen+9+5900X+12-Core 的比较，点进去之后你会发现双路 E5 总体是连 5600X 都不如的，但是在个别子项里面可以压着 5900X 打。这就是为什么要搞清楚需求，很多人喜欢把性能问题简单化，比如“A 比 B 强 XX%”，但是实际情况是每个 workload 的性能特征是不一样的。如果你的需求是这些 E5 有优势的 workload ，那你才赚大发了，反之就亏大发了，哪怕核数很多（因为其他很多子项是 5600X 压着 E5 打的）。上面有人说 GB 跑分，GB 依然是一个综合性的跑分，一般的 GB 结果不会给出每个子项的分数（我甚至不清楚 GB 免费版有没有给出这个信息的能力）。

至于为什么你觉得 E5 性价比比较高，这个要从市场的角度去考虑，E5 确实是不适合桌面应用的，所以大多数个人用户不会接盘，企业用户大概也没有这个需求。个人用户的特点就是需求非常多且杂，所以万金油比较吃香，服务器硬件有明显短板就不受欢迎。而如果你的需求恰好匹配的话，那这个市场恰好给了你放弃不需要的特点来换取更低价格的机会。
另外虽然我不喜 DIY 圈，不过该圈有一个说法叫“板 U 守恒定律”，就是有时候有的 CPU 定价比较便宜，那主板可能就比较贵，最后价格并没有便宜多少。这个依然主要是指 MSDT （并且存在一定的 bias——因为 CPU 和主板都很没有性价比的组合都自动被过滤掉了）。但是在这里依然需要考虑除 CPU 以外的平台价格，因为我不清楚现在 X99 能不能找到便宜靠谱的板子，而 AM4 是可以买到很便宜的主板的。并且主板作为比较复杂的部件是比较容易出问题的。

@monetto

> 需要不断的 cd + ls ，进行大量操作的时候，莫名感觉繁琐。。。

如果仅仅是这个问题的话，既然你有别的设备可以 ssh 进去，那可以映射一个 SMB 或者 sshfs 之类的东西
Terminal File Manager 我也用，但是感觉效果并没有好到哪去

@zuobinwang 你还是没说清楚具体是什么，“顶层”是啥？