Fleet 的资源占用很高，可能是因为运行在 debug mode ( https://news.ycombinator.com/item?id=33177860)

至于为什么 Jetbrains 要从零开始开发 Fleet ，我觉得是因为 remote development 所需要的架构是目前 IntelliJ 无法支持的。要想获得 VSCode remote 的体验，编辑器 /IDE 必须要把交互层和文件层分离开，从这个意义上说，Neovim 的前后端分离和 Xi-editor 的架构都是不能支持 VSCode Remote 的类似体验的，因为他们只是把渲染层分离开了，而延迟感受最重要的键盘鼠标输入还是放到了“后端”。我试验过 VSCode Remote 到一个 300ms 延迟的机器上，编辑本身是没有延迟的。

再说说 Fleet 的插件，因为前后端分离，Fleet 的插件和“前端”必须要通过 RPC ，而 IntelliJ 的现有插件是直接运行插件的 Java ，要想让 Fleet 支持现有插件还有很多工作要做，而 Fleet 的“后端”是 Rust 又进一步增加了难度。

@zxCoder

user@host 这样，port 还不支持 :)

@zxCoder

目前支持 key authentication ，密码目前不支持

@imzcg2

插件文档还没有完成 :)

Druid 挺好用的，自创控件功能特别强大

@bitdepth GPU 渲染文字一般都是 cache 到 pixelmap 上，字母和中文的速度是一样的，区别是中文的 memory 会多一些，因为字符会多很多。

@irytu 当然，应该已经有一个 issue 关于这个的

@justin2018

brew 好像有人添加了

@okampfer

没有用过 fleet ，但也一直在关注 fleet ，看反映感觉也还是挺早期的。

性能上说的话，Fleet 如果没有 aot 还是会有启动速度的问题吧。然后看 Fleet 的 blog ，他们也是用了 rope ，所以编辑大文件应该也是没有任何问题。

最开始使用 wgpu 就是因为 wgpu 是目前比较现代的 API ，但是一直有用户会反映 Lapce 会直接打开时崩溃，换了 opengl 之后基本都解决了，奔溃的原因一般是双显卡和 vulkan 驱动的一些问题。

还有一个原因就是 wgpu 目前还不支持 dual-source blending ，等 wgpu 更稳定一些然后这个功能支持之后我们还是会切回 wgpu 的，大部分代码都是相通的。

web 平台也是在我们的计划上的，因为底层的 Druid 都是可以支持 web 的，然后具体实现基本上就是在 canvas 里面画，跳过 dom 这一层，性能上应该还是有保证的。

@t123yh

这个是我缺少经验导致的，现在修了一部分了。

@agagega

主要是速度的考虑，在高分辨下，CPU 渲染 Text 已经是个瓶颈，GPU 渲染的延迟能控制在 2ms 之内

@magicdawn

是 L(ightning-fast) a(nd) P(owerful) C(ode) E(ditor)

@xdeng

有的 https://lapce.dev/#downloads-all 选 portable

@abersheeran
@irytu
@dreamramon

再请问一下你们是用的 DX11 还是 DX12 ？

@abersheeran
@irytu
@dreamramon
请问你们是什么系统？

我在 Reddit 上面大家的回复都是说跟 Sublime Text 一样快。

@bilberry 楼主方便留一个邮箱吗，想要交流一下，我也在 Guildford

@bilberry 楼主在 Surrey 读什么专业呢？

@PressOne 怎么可能大公司不用容器，k8s 怎么出来的，就是 google 把自己的容器管理系统拿出一些出来开源了。