楼主提到了 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 ，流程上会有额外成本。

这个是你选错了赛道，如果是 VFX 领域的软件，Python 是业界标准，所有主流软件都带一套 Python API ，你不带是你的问题（这个大概是十年前开始的趋势？）。ML 领域同理。相似地，在 EDA 领域，Tcl 是标准； Web 前端领域 JavaScript 是标准； Gamedev 的话 C# 和 Lua 多一些。

所以对于“Python 作为扩展脚本常不常见”的回答，更合适的是“有些地方常见，有些地方不常见”。而正是因为楼主试图用一套解决方案照顾不同群体，那就必然出现这类问题。Python 和 JavaScript 都只能 cover 到一部分人，楼主接收到的反馈可能存在幸存者偏差，也许如果楼主当年用了 JavaScript ，就会有另外一批人出来喊为什么不支持 Python ...

至于后面的两条问题，这个就和用哪个语言无关了，工具和生态是所有项目永远的话题。

我个人的思路：
* 扩展 API 不局限于单一语言。这个有三个具体的例子，第一个是很多 C/C++ 项目不会直接提供脚本语言的 binding ，而是直接暴露 C API ，几乎任何地方都可以用 FFI 调用，对于各个语言的 binding 由社区维护单独的项目；第二个是各种 Web 服务同样是只暴露统一的 Web API ，不下沉到具体语言；第三个是 Web 里的 DOM API ，同样并不以语言特定的形式定义，而是使用一套单独定义的 Web IDL 语言定义，这个稍微好一点，因为能直接映射到 OO 语言。
* 同样地，解决编写体验问题，不局限于传统思路。而是使用可视化编程的方式，这个也是在 VFX 等领域中被广泛推广的。可视化编辑器和传统文本编辑器本来在设计思路上就有根本性的不同，比如可视化编辑器一般天然要求在某一个地方要有一个对所有操作的列表/搜索框，这在传统文本编辑中是不必要的。
当然这套东西摆出来，并不是对楼主的建议，它不一定适合一个具体的实际问题。这只是我对一个理想的扩展系统的构想。

楼主的显卡配置是什么？
现在这种方案有一个问题是如果想在 Windows 和 Linux 上同时保持较高的图形性能有一定困难。就最近几年 PC 的发展来说，MSDT 平台对多显卡越来越不友好。

我不知道你说的“二创”具体指的什么，在现代互联网语境里，这个“二创”可以指一切 derivative work ，包括但不限于内容增强、修改补丁、小说、音乐、绘画、视频、实体周边，甚至互联网迷因，行为艺术和作弊辅助。War3 语境里可能指的主要是地图。但是就广义的二创而言，我不觉得现在的生态，哪怕是手游，是严格意义上输给当年的（其实这也是版权法定义，所以只要开发者不挥舞版权大棒，这个二创生态和流行度是有一定正比的）。

而就狭义的对游戏本体的修改来说，一方面因素是 RTS 本身这个 genre 的特色：天然能做很多单位，而只 focus 少量单位也还过得去，视角拉得远避免了社区在 graphics 方面的短板。另一方面是如果我费了半天劲把一个游戏变成另一个游戏，为什么不自己重新开发一个游戏，不受原来限制，还能卖钱？所以我觉得现在各游戏的圈子多在回归本体，做得最多和最受欢迎的都是增强游戏本体体验的。要 total conversion 甚至 genre 上的变换，去玩另一个游戏。

时代确实变了。现在互联网给普通人提供的创作方式、工具和资源和当年不可同日而语，一个人在当年可能做 War3 二创，现在可以做独立游戏，做 YouTuber ，做开源软件/硬件，玩 AIGC 。就是在游戏圈本身，游戏选择也更加丰富了，moddable 的游戏也更多。就算 RTS 现在像 MOBA 一样火，在单一 IP 中找过去的生态还是有点刻舟求剑的味道。

个人感觉，服务器平台，ECC 和 PCIe 通道以及 IPMI 确实是好东西，CPU 稳定性上和 MSDT （默认配置）差不多，主板就不好说了
（然后我查了一下发现华南有些板子就没给 IPMI ？）

内存带宽的话因为现在 DDR5 换代，如果只是刚需高内存带宽，现在这个阶段 MSDT+超频 DDR5 也能顶到 120GB 左右，比单 E5 老 DDR4 要高出不少，理论值跟 SKX 差不多（实际不清楚，可能能跟 CLX 比）。再往上可以收块 Rome ，果子也凑合（就是容量太憋屈）。现在最猛的貌似是 TR7000+超频 DDR5

背这玩意确定不会引起引力异常么

生态好首选 Unity 啊

老用户表示 Linux 其实好像也有内存泄漏的 ...
about:memory 看下，我的经验是长时间使用之后 style-sheet-cache 之类的会膨胀到很夸张的地步

而且几 ms 就完成不能得出搜索时 CPU 占用很低的结论，任务管理器一秒更新一次数据，那么把 CPU 占满 10ms ，你看到的也就 1%的占用率变动，这个甚至不如日常使用时其他进程的波动大 ...

Linux 也有 locate ，考虑参考一下？

那看起来可能是都不用 Firefox ... which 非常可以理解 ...

另外楼主倒是不用担心这贴沉不下去。V 站排序对于老贴很不友好，而且有些节点貌似被降权了，很难出现在列表里。

@shendaowu

> 我觉得你是有那个能力的，毕竟你对无关的人的不适好像挺在乎的。但是你为啥不把这种能力用在我身上呢？因为我犯错，所以有罪，所以没人权？

我“在乎”的表现是“谨慎”，不是无条件地迁就。我认为我这种做法是适合我的，如果在我认为我没有恶意的情况下，别人觉得我存在恶意，那么我只能解读为别人的问题。

> 有可能是我敏感的问题，我确实敏感。但是相对来说我觉得看你说的东西还是比别人的情绪负担大。另外我有病，双相，最好是减少情绪刺激，否则容易犯病。

不如说，我好像也有？不知道。

> 你可能认为我会为了营养一直忍受难吃的东西，这个应该是圣人的境界。我虽然想当圣人，但是目前来看希望好像不大。

当圣人本来就会有很大负担。
我从来不想当圣人，所以我也不觉得我的东西有什么“营养”，你如果这么认为的话那你可能又错了。“味道”确实有，就好像花有味道，狗也有味道，但是花变不成狗，狗变不成花。我如果换了“味道”就不是我了。

> 具体比如说你的那个发文和提振信心我一眼看过去就是在讽刺，我尽力想看出点别的意思但是失败了几次就放弃了。

同样的意思，我在 #12 最后说了一次，看你好像没太明白在 #19 最后又说了一次，最后又在 #20 说了一次。你还是没明白的话我觉得我也没必要继续说了。
你可以认为这是一种“味道”，话说得太明白，交流就没意思了。

不知道楼主学没学过 C ，C 里面是没有内置的 min/max 的，取两个数的最大值需要 a > b ? a : b
然后有的人喜欢定义一个宏 #define MAX(a, b) a > b ? a : b
又因为 C 预处理器宏是文本替换，所以这个会有各种坑 ...
（为什么不定义函数？因为 C 直到 C11 才有个凑数的泛型 ...）

我看主题里都是假设有个容器，然后在容器里的数取 min/max ，但实际编码时很多时候就是算法需要在固定的数中间取，比如我算出一个 a ，a 可能是负数，我不想返回负数，就用 Math.max(0, a)，因为有了这个库函数，所以不需要写 a > 0 ? a : 0 。
自己去 GitHub 上面搜，用解构取数组 min/max 的反而难找 https://github.com/search?q=Math.max&type=code&p=1

类似的加法直接用 + 就行了，不需要一个专门的函数
算是强行找点借口吧 ...

所以我个人建议楼主的思考可以在“解释”上加上“沟通”或者“反馈”，“解释”是单向的，“沟通”是双向的。单向的“解释”会让人觉得 condescending ，会让人越来越不满意。有时候人们不满意就是规则有修改的空间，包括人们不理解机制，而需要“解释”，这本来就说明产品的友好性需要提升。