Hacker News Reader

Comment by timfsu | Hacker News Reader

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.

View on HN

Check 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.

https://github.com/zed-extensions/tsgo does exactly this

That doesn't make sense, they both use tsserver under the hood.

You 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.

Could, ya, but I'd be pretty impressed and sad if Rust didn't have really good JSON parsers/serializers by now.

It’s had them for a very long time, pre-1.0.

What do you mean? It has exceptionally good crates for that, and has for more than a decade. Is there something you feel is missing?

Well 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.

I've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP

To 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..

As 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#issuecomm...

VSCode'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

I 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

Electron compiles NodeJS with v8's pointer compression which leads to an up to 50% decrease in memory usage, and might speed it up too.

Are 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?

Reply on news.ycombinator.com