Hacker News new | ask | show | jobs
by elevader 1512 days ago
The net benefit of using the "separate processes using IPC" model lies in the fact that the language used is an implementation detail that editors/IDEs don't have to care about. Want to write your Rust Language Server in Rust? Fine. Want to write it in Kotlin? Also fine. Your editor is written in JS? Cool. Elisp also works. This wouldn't really work so well if LSPs were some sort of library. IntelliJ plugins are great (if they exist) but they are inherently limited to their own ecosystem, nobody outside of that benefits from that. LSP sure isn't perfect but it is a hell of a lot better than the situation we had before it. If IntelliJ works well for you then that option is always there and hopefully here to stay, all power to you. But not everybody wants that.
1 comments
mike_hearn 1512 days ago
You can load code written in different languages into different address spaces, you know. Nothing stops Emacs loading a library written in Rust or indeed Java/Kotlin.

Microsoft didn't go that way and again it feels like maybe JS limitations are the cause. Calling into a native library is tough in JS because there's no standardized FFI (browsers wouldn't allow it) and you're going to end up blocking the one JS thread you've got. Native code is going to expect the host to be able to spin up threads and use them because that's a super reasonable assumption, but one V8 can't meet. So they want everything to look like a web server because that's what JavaScript is intended for. That pushes them down a particular path, but it's definitely worth stepping back and saying ... does this really make the most sense, overall?

link
adwn 1512 days ago
> You can load code written in different languages into different address spaces, you know.

That's basically what separate processes are, so what's your point?

> Calling into a native library is tough in JS because there's no standardized FFI

No need for using anything standardized: VS Code brings its own custom browser engine – for better or for worse – so it's not limited to what any Web standards allow or forbid.

> you're going to end up blocking the one JS thread you've got

There are worker threads in JS.

link
mike_hearn 1512 days ago
Er, sorry, that was a brainfart. I meant you can load them into the same address space.

JS has workers but they aren't sharing memory, so they aren't really threads.

link