@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 现在越来越不一样了，能分开还是分开。

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 ，流程上会有额外成本。

这个是你选错了赛道，如果是 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 平台对多显卡越来越不友好。