5 ms·
Unfortunately, I tried to use zed as my daily driver, but the typescript experience was subpar. While the editor itself was snappy, LSP actions like "jump to de
by timfsu 1y ago
Unfortunately, I tried to use zed as my daily driver, but the typescript experience was subpar. While the editor itself was snappy, LSP actions like "jump to declaration" were incredibly slow on our codebase compared to VS Code / Cursor.
- 0x696C6961 1y agoThat doesn't make sense, they both use tsserver under the hood.
- foobarbaz33 1y agoYou could have an lsp server of infinite speed, but that wouldn't help one bit if the bottleneck is how the client deals with the messaging. The specific techniques used to send, receive, and parse JSON could matter.
- hdjrudni 1y agoCould, ya, but I'd be pretty impressed and sad if Rust didn't have really good JSON parsers/serializers by now.
- steveklabnik 1y agoIt’s had them for a very long time, pre-1.0.
- adastra22 1y agoWhat do you mean? It has exceptionally good crates for that, and has for more than a decade. Is there something you feel is missing?
- socksy 1y agoWell exactly, I'm pretty sure that's what the GP is getting at — it would be a surprise if Rust didn't have good JSON support. Which it does. So it's unlikely to be the bottleneck.
- brundolf 1y agoI've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP
- CapsAdmin 1y agoTo expand on this, the vscode editor can do a lot more than what is specified in LSP. You can have custom functions in your language server that is not in spec and have your editor specific plugin call them. I imagine there is a lot of this for typescript. But I'm not sure if this can explain the speed difference..
- antmarti 1y agoAs the owner of a somewhat popular language, I checked to see if there's an extension available (there is!) as we publish a language server. One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug. EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomment-3410498828 https://github.com/zed-industries/zed/issues/18698#issuecomm...
- rs186 1y agoVSCode's TypeScript service does not currently use LSP, and many language queries run in the same thread as the extension (or "Extension Host"). That does not necessarily explain the performance difference though
- brundolf 1y agoI had the same experience and the same outcome. Zed was super fast for editing but slow for rich features, which on the net slowed me down compared with VSCode
- adhamsalama 1y agoElectron compiles NodeJS with v8's pointer compression which leads to an up to 50% decrease in memory usage, and might speed it up too.
- davidatbu 1y agoAre you saying that VSCode runs tsserver in its own NodeJS process? Or are you saying that VSCode uses the NodeJS it ships to run tsserver in a different process?
- homebrewer 1y agoCheck if it supports using typescript-go as your LSP. IDEA recently added this, and I've been using it for a couple of months already; it's fantastic.
- osener 1y agohttps://github.com/zed-extensions/tsgo https://github.com/zed-extensions/tsgo does exactly this