每个 ISA 都有自己的坑，不好说哪个编译起来更复杂。同一个编译器，不同后端下的功夫也不一样，你可以只做最基本的指令选择寄存器分配，不做优化，就说我编译没编译吧。就不说不同编译器版本和编译选项的坑了。这个还可以套娃：就是你编译器本身是怎么编译的？就不说拿 -O0 的编译器来跑这种老六行为，就现有主流编译器，过一遍 LTO+PGO 或者 post-link optimization 就能有两位数百分点的提升。

最好还是统一编译到同一架构来比较。
而这个图压根没有给出任何相关信息，作为性能比较是不合格的。


@agagega #6
> 编译时间绝对大头肯定是优化，这部分和目标平台没啥关系。
感觉真不一定，几个重量级：C++，Rust ，Haskell ，Scala

@james122333 他说的是不用折腾。
这也是 macOS 和 Windows 的问题——没有给出选择。HiDPI 下还不太明显，老设备下就各有各的问题了。

之前 OS X 的 System Preferences 里面有个 “Use LCD font smoothing when available”的选项，应该是影响是否使用 subpixel rendering ，打开之后会显著增强视觉字重，对就很类似 #23 那种胖了一圈的感觉。根据网上说法，macOS 后来不知道在什么版本里面，把 subpixel rendering 整个砍了，这个选项也没了，但是 defaults 里面还在，效果变成了让字体自动加粗一圈，但是这是两年前的说法，新版可能又不一样了，反正我复现不出来。
但是 anyway ，两个系统的 hinting 都是不给调的。

你给的这个配置 hinting 看上去直接满了，应该是更偏向 Windows 那种的。虽然我记得 KDE 好像默认就是这个风格，不过本贴里大部分人估计不怎么喜欢。不过问题就是，你不让用户配置就有一半用户不喜欢，你让用户配置用户就嫌麻烦。
而且我这 Qt 和 GTK3/4 程序的字体渲染好像有明显的不一致，这个倒是更加严重的问题 ...

@zhwguest 不是说"goto 导致反编译失败"，所有 control flow 到字节码里面都是 goto ，只是反编译器能不能从 goto 里面还原出原来的 control flow 来。

淘宝的生态位是多样性，鱼上甚至有卖光刻机零件的，真不真不知道，但是作为这一特色的极端体现，看个乐子还不错

大牌和爆款，确实京东和拼多多好，问题是这个世界不是只有大牌和爆款的
我估摸着淘宝自己也没搞清楚自己的核心竞争力在哪，体验也没见变好，他要硬跟其他两家拼我不觉得有胜算，以阿里的效率，光靠利基市场能不能养活自己也难说

逻辑可能是 locality ，你频繁使用的服务器能记住图标，不频繁使用的去找一下问题也不大，节省了 screen real estate
不过我本来用得就不多，我觉得 Discord 除了 Server-Channel 这个二级 hierarchy 的设计之外其他都挺烂的

改改 CSS 可能能部分解决

这个问题隔壁有过讨论 bbs.saraba1st.com/2b/thread-2166778-1-1.html 说起来，为什么国内 win7 仍然有如此高的占有率 - ＰＣ数码 - Stage1st - stage1/s1 游戏动漫论坛

本站看起来也没好到哪去，大多数回复 totally miss the point ...

C/C++ 反编译里面这种情况非常常见，比如你用 Hex Rays 或者 GHIDRA 反编译稍微复杂一点的函数很容易出现一堆 label+goto 的结果，虽然源代码 90% 不是这么写的。其实就是 C/C++ 编译器优化得多

这个看起来是 JVM 支持 goto ，但是 Java 不支持，然后你这个 bytecode 可能是 Kotlin 编译器生成的不是 Java 编译器生成的。你直接用 Java 构造可能会比较困难，但是对已有的 bytecode 做后处理达到这样的效果倒是有可能。

买 Studio 的默认不差钱，拿点零头出来捡个垃圾游戏用就行了。
Mac 和 PC 现在越来越不一样了，能分开还是分开。

rsync -x 把文件全都拷下来就行
不过我是把包列表 + /etc 下改过的东西备份，包重新装一遍配置一覆盖就行

WSL 还是先解决这个问题再说吧 github.com/microsoft/WSL/issues/6982 Vmmem high CPU usage · Issue #6982 · microsoft/WSL

楼主提到了 Apple 的后端服务，我感觉这个项目的关键点应该是可以转换成多种已有格式。我的猜测是 Apple 可能用了一堆开源项目，不同开源项目有不同的配置格式，本身量又多，就搞了一个这玩意统一管理。其他的 feature 都是围绕这个目的做的。

算是把 Cunningham's Law 玩儿明白了 ...

@murmur Adobe 用 JS 和 Electron 关系可能真不大 ... 我觉得更有可能是 Adobe 本身跟 Web 绑定得更紧，甚至是之前占据现代 Web 生态位的，收购来的 Flash （以及后来的 Air 之类）以前用的也是 JS 变体。SpiderMonkey 引擎用的 nanojit 后端甚至还是 Adobe 从 ActionScript 实现里面抠出来的 ...

我目前在 Mac 上准备拿它替代 Sublime ，而 Sublime 现在对我来说则是 TextEdit 的替代品 ...
而 VSCode 则是 VS/Xcode 的替代品（别跟我说什么编辑器和 IDE ，对于大多数人来说，家养的只因和工业养殖的只因不存在本质区别），所以这俩现在是不同的定位。
从大菊来看，对我来说 VSCode 如果能有一个像样的竞争者是最好，没有也无所谓，所以不指望能替代 VSCode 。

并且现实情况上 zed 目前也确实存在一些缺陷，比如暂时只支持 Mac 是一个，还有一个是让我第一次打开就蚌不住的——一个只 target Mac 的软件，UI 上的所有文字居然全都是等宽的！（虽然可能实际上不是严格的等宽，有一个说法是“quasi-proportional spacing to allow the font to still feel monospace”——总之设计意图依然是等宽的）
这样的审美你跟我说是 Atom 的人做的，真的有种在开玩笑的感觉。官网更加搞笑，不同的图片使用的是不同的字体。

至于在我这完全替代 VSCode ，各种功能我觉得是次要的，毕竟 80% 的人只会用到 20% 的功能，除了完善主要平台支持之外，下面几点很重要：
# Remote Development
或者支持 Web 从而能够像 code-server 一样在浏览器中使用远程的编辑器，以支持在服务器上开发。这些都在 roadmap 里面，做到一个就算它合格。
当然有一些微妙的区别，比如像 Remote Development 或者 Collaboration 这种东西，要做到最好的体验，最好是要在编辑器底层架构设计时就考虑进去，所以一做就必然是很大的东西，不可能做成单独的插件。
比如 VSCode 是单独分出来了一个 extension host 进程，然后定义了一套 RPC 协议。而按照 vscode-remote-oss 项目作者的说法，VSCode 官方的 Remote 插件提供的仅仅是把这套架构通过 SSH 连接起来的 integration （所以 TA 就自己造了一个）。虽然你可能不用 Remote ，但是纯本地使用跑的依然是这套架构，所有的操作都要过一遍 RPC 。甚至就连 Vim 模式这种功能也有这方面的问题（ VSCode GitHub 上 vote 前三的 Issue 有一个就是要原生的 Vim 模式的）。
VSCode 在这方面还有一个优势是它自己是用 Web 写的，所以直接就能跑浏览器上，而试图在浏览器上搞 DirectUI 的，我还没见过能保持一定复杂性的前提下能做得体验特别好的。

# 插件生态
不仅仅是常用插件，我还比较依赖一些长尾插件。比如 ccls 替代官方的 C++ 插件，Codeium 替代 Copilot ，还有 OCaml Platform 这种小众标准插件。虽然我的用法是尽量少装插件，但是以上几个依然是关键依赖。
这些其实都和 MSFT 自己没关系，都是社区开发的。现在大家做一个工具，一般至少都会考虑 Vim ，VSCode ，Emacs 几个编辑器，再多点加上 NeoVim ，Sublime ，还有 JetBrains ，VS 和 Eclipse 三兄贵，新玩家能挤进第二梯队就算成功。
VSCode 有一个天然优势是它和 TypeScript 共同成长并且建立了良好的共生关系，VSCode 使用 TypeScript 编写，VSCode 同时又为 TypeScript 提供了良好的编辑体验，而由于有 VSCode 提供的良好编辑体验，TypeScript 也更容易推广。类似的模式其实不止出现在 VSCode 中，比如至少在 VSCode 流行之前，Emacs 上的一些小众语言插件就能提供比其他编辑器更佳的体验，比如 org 是天然绑定的，以及 proof-general ，merlin 等等，当然还有各种 LISP 。
这么玩的一个好处是虽然其他语言的人不一定会用你，但是这个特定语言的群体你是吃定了，有了稳定的基本盘。Zed 不是不能走这条路，比如可以试着成为 Rust 的 de facto 开发环境，不过各方面相比 VSCode 和 TS 的先例都要难太多了。

# 商业化计划
Zed 和 lapce ，xi 等之前在 Rust 前线出现的新编辑器（ helix 很难放在一起比，因为貌似还没一个能用的 GUI 前端）的本质区别，我觉得是 Zed 一开始就是作为一个商业项目打造的。我是大概 1 月中旬开始关注 Zed 这个项目的，当时是看到了他们关于 GPU 的文章，顺便看了一下编辑器，当时觉得很好但是兴趣不大，因为它不开源，我不会把我工作流中的 critical path 跟一个不完善还闭源的东西关联起来。没想到过了一周就开源了，看起来官方的意思是编辑器开源（ copyleft GPL/AGPL 防止别人直接用，同时 CLA 要求所有 copyright 归 Zed 公司这样自己可以用），然后卖服务。
这里存在两方面的问题，第一是这个商业模式是否可持续，比如现在唯一有点谱儿的 Zed Channels 能有多少实际需求（如果 Zed 本体做得不错的话可以考虑情怀性支持，不过这种支持终究治不了商业模式基础性的问题）。我其实根本不在乎 Zed Industries 能不能活，因为就算他们死了，一个开源项目扔给社区还是能继续做，但是如果过早地死了，项目完成度太低，生态太差，那估计结果还不如 Atom 。
第二是他们以后会在什么地方下刀，比如 VSCode （和 Nadella 时期 MSFT 不少类似的热门开源以及非开源项目）到现在来看，其实依然在走一个老 EEE 策略的变体，当然对于 VSCode 来说，可以做到只闭源不收费，但是 Zed 大概做不到，比如 Remote 要是收费，那就比较要命了（虽然这个可能确实是不错的收入）。
另外一个情况是我这如果是在工作中使用的收费软件的话，原则上需要报备审批预算，不能私自买，Freeware 也需要审核 License ，流程上会有额外成本。