It's important to note that this isn't a dev response that is meant to directly address the issue in the OP. Someone else just saw that it was a dev comment in a related issue and linked it.
If you look at the linked thread the quote came from [1], the quote is actually answering a similar issue titled "Why are there nodejs files in my zed install". Judging by the response, the dev had interpreted the issue title as a "what does zed uses nodejs for" and not "why does zed downloads nodejs without informing the user" and answered accordingly.
There are more relevant links to PRs and comments further down the GitHub thread (the one in the OP) where the zed devs acknowledge that they are still thinking about how to best implement the UX for extensions downloading LSPs and whatnot.
That is about the idea of rewriting existing tooling in Rust to get rid of node_modules folders, not about prompting users whether to download a language server or not.
"Action would be too difficult / we don't like it" =/= "there is no action available".
This is just refusing to take responsibility for their decision. "We don't feel like doing it" is the truth, and it would be best to state it plainly. Of course there is no obligation to do otherwise, which makes it strange to play with words.
That's nothing to do with having a dialog to ask for each too. That's talking about the amount of work it would be to rewrite all these tools themselves so it was first party Rust code.
That's not a Rust issue (not having a prompt to update LSPs). Lapce[1] is also a Rust editor, and it didn't keep downloading JS or stuff without a prompt. You can do what VSCode does, have extensions that ask for update, then update on change (even if using binary is the only solution, which I also doubt). Or if the issue is running LSP, ask if you trust a project folder on project start.
There are more game engines written in Rust than games written in Rust.
So maybe there are more GUI libraries than dialog windows written in Rust as well.
The referenced issue has nothing to do with Rust. One would have to dug deeper and not relay on random comment to figure out. So I'm not expecting you to do it when even content of your comment is bit lazy copy-paste.
But even so, without checking the actual Github, it was already explained here [0], before you have posted.
It's important to note that this isn't a dev response that is meant to directly address the issue in the OP. Someone else just saw that it was a dev comment in a related issue and linked it.
If you look at the linked thread the quote came from [1], the quote is actually answering a similar issue titled "Why are there nodejs files in my zed install". Judging by the response, the dev had interpreted the issue title as a "what does zed uses nodejs for" and not "why does zed downloads nodejs without informing the user" and answered accordingly.
There are more relevant links to PRs and comments further down the GitHub thread (the one in the OP) where the zed devs acknowledge that they are still thinking about how to best implement the UX for extensions downloading LSPs and whatnot.
[1]: https://github.com/zed-industries/zed/issues/7054#issuecomme...
That is about the idea of rewriting existing tooling in Rust to get rid of node_modules folders, not about prompting users whether to download a language server or not.
"Action would be too difficult / we don't like it" =/= "there is no action available".
This is just refusing to take responsibility for their decision. "We don't feel like doing it" is the truth, and it would be best to state it plainly. Of course there is no obligation to do otherwise, which makes it strange to play with words.
That's nothing to do with having a dialog to ask for each too. That's talking about the amount of work it would be to rewrite all these tools themselves so it was first party Rust code.
That's not a Rust issue (not having a prompt to update LSPs). Lapce[1] is also a Rust editor, and it didn't keep downloading JS or stuff without a prompt. You can do what VSCode does, have extensions that ask for update, then update on change (even if using binary is the only solution, which I also doubt). Or if the issue is running LSP, ask if you trust a project folder on project start.
[1]https://github.com/lapce/lapce
Does it mean that it’s excruciatingly difficult to write a yes/no prompt in Rust? You can make an editor, but not a consent prompt…
There are more game engines written in Rust than games written in Rust. So maybe there are more GUI libraries than dialog windows written in Rust as well.
The referenced issue has nothing to do with Rust. One would have to dug deeper and not relay on random comment to figure out. So I'm not expecting you to do it when even content of your comment is bit lazy copy-paste.
But even so, without checking the actual Github, it was already explained here [0], before you have posted.
[0] https://news.ycombinator.com/item?id=40903577