Pretty much all of it seems to be on golang.org, github.com/google, or are by people working on gopls. The suggestions that there are tons of dependencies from random people is just not true.
In my mind, an IDE needs to be able to read all the files I can read myself, it needs to be able run arbitary tools like compilers and linkers then run the resulting compiled code, it needs a debugger that can attach to running processes and mess with them, it needs to be able to pull from the language's package repository when you ask it to, it needs to talk to your git server when needed, it needs access to your SSH keys to do that. About the only thing the IDE doesn't need is to run as root - and if you're working with Docker it basically needs that too.
The idea of an IDE with pluggable language support safely running plugins from untrusted sources? I can't imagine how such a thing could even be possible?
Also supply chain attacks are a freight train barreling down the tracks. The gate is down and the crossing bells are dinging but our car is stuck on the tracks.
Ever since the xz thing almost worked every black hat group on the entire planet is trying their hand at this. The days of software dev as a high trust environment are going to be over fast.
It works really well for us and prevents potentially bad extensions, python libraries, etc exfilling our code, data, etc.
It there a decent alternative for Golang on the Visual Studio Code marketplace?
- Zed is (currently) free
- still pre 1.0 release
- being developed quickly by a small group of developers
As someone who's maintains OSS myself, the onslaught of people who can swarm in fast to piss on your hard/long efforts can demoralize you.
So let's be kind in our words (and tone) to these folks.
(It doesn't make it right, all I'm saying is - showing compassion goes a long way with developers while they re-evaluate)
If you open a file for that language, is there ever a time you would deny the download?
I just don't want a huge amount of popups like VSCode.
Also, the binaries are downloaded from their release on github. As long as that is secure I don't see a problem.
Here's an idea: someone sends a dev at some company, or even a freelancer, some code. Code references a module with a malicious npm package (say, with a postinstall script). Dev opens it in zed
Now, my untrusted code is running on your machine, probably without your knowledge
The code itself could be malicious and have backdoors. Really you shouldn't run anything untrusted outside a sandbox or some other form of isolation
Unless you’re auditing everything while taking Trusting Trust into account, you’re drawing the line somewhere saying “ok I can’t be bothered past this point verifying”.
… everyone has a line somewhere on the trust-but-verify spectrum
everyone
> If you open a file for that language, is there ever a time you would deny the download?
every time
default should be offline imo. want to download something? do it manually and place in folder etc
Are you really so self-centered that you can't imagine anyone doesn't care?
I'll raise my hand and say I personally am happy to trust Zed and am fine with auto-installing whatever binaries they propose.
I do think it's reasonable to have an option for people with different security postures, but don't assume you speak for everyone.
Not true, everyone is not you, I don't want to.
absolutely incorrect, i loved that it does it for me and do not care even in the slightest and in fact this is 1000x preferable to vscode asking me.
what on earth made you think this was a reasonable reply.
If you use Zed you must have known the language server was running when you tried it, how did you think that was happening?
And these modern editors introduce another issue with their modularazied design. For each supported language Vscode installs tons of other crap beside the language server itself. And the language server alone has a quite long list of dependencies
https://github.com/golang/vscode-go/blob/master/extension/go...
1: https://github.blog/2024-05-02-introducing-artifact-attestat...
However, sometimes (very often) you need to explore the API and just check every available method and check their docs to find which one is appropriate to use.
So, even though I can see AI replacing a lot of auto-completions, it just can't replace it completely.
I think you're asking the wrong question. The correct one would be: "who wants to be asked if they want to approve and configure all of their language servers?"
It's not what zed does, it's doing it behind your back!
What's really funny is it was found because it was crashing and the user was running another libc. If they're really concerned about 14MB of download, they should add a firewall or something, but they saw it crashing. Finally, all these versions of everything sitting around, nodeJS, glibc, etc, very UNIX, a recipe for small breakages. Though I guess that's just the problem we deal with.
Questions: What control does a user have right now over what gets installed automatically? What are the levers we can pull to get more control? (These levers include configuration options, pushing back on the project, and so on.)
P.S. Not that this is an excuse, but VS Code's security posture (sandboxing, prompting users, etc.) probably didn't happen overnight without user pressure. Who knows the history?
> Ideally you would be able to turn off auto-download but still be able to use a [language server] if it’s already on the users system.
> There is not a binary choice between "friendly to end users" and "secure". You can have your cake and eat it too. The main thing that should be considered is less of a user facing popup or preference (where opt-in vs. opt-out is an issue, as is noise & friction), but developer facing options. If Zed offered compile time configuration this could be fixed to everybody's satisfaction. Distros could ship a pre-configured package with all the dependencies already provided so that the user experience is just "install and run" while also not having an app that downloads (or attempts to download) binaries behind teh users back. Meanwhile if Zed wants to ship a binary package upstream that defaults to downloading things they can.
The good thing is that this can be turned off with this option: "enable_language_server": false
With Zed, I have another issue. I don't understand which niche it is trying to fill. The advertising story doesn't convince me. The performance bottlenecks are typically the LSPs after all, not if text is rendered in 10 or 20 ms. Startup time is secondary. Yes, memory usage is a concern. I get that and that's where Zed is miles ahead of VS Code and Jetbrains IDEs. But overall I think:
- If you want easy and free, go VS Code.
- If you want ultimate IDE features and mouse and GUI, go Jetbrains.
- If you want ultimate productivity, follow this beautiful guide: https://lazyvim-ambitious-devs.phillips.codes/
But what they should have is a CDN with their own extensions and verified binaries. This way they can ship new versions of extensions without bumping their editor version.
How many language servers are we talking about here for the average dev? Three?
That strikes me as more of a UX problem. Doing a bunch of sketchy things behind the user's back is absolutely not a solution though.
Once you've done that, it's similar to emacs for me, everything has to be evoked via a shortcut (or Action Palette which works very well in VS Code). The shortcut to show "help" or "docs" is Cmd+K Cmd+I, by the way - easy to type and remember...
Why is showing the release log the default for so many things? Is the average user really going to read them?
It makes you wonder what they are doing with all that telemetry
It's the "modern times" craze about plugins pulled from different unauditable, unknown sources. The fact that it is on GitHub or any other "publicly available" source it is irrelevant.
I keep using vim and Kate and manually install anything I need form my distro (Arch Linux) repos. If it is not there, then, sorry I cannot use it.
I don't think it has to be this way. I think we can have both better compartmentalization and tighter workflow integration without having it becoming a part-time job.
Here is my ongoing attempt at addressing the issue, currently scoped for neovim[0]:
https://github.com/legobeat/l7-devenv
(I did share this to crickets as a Show HN the other day, hope it's on-topic enough to OK to reshare here)
[0]: The same framework should, at least in theory, be extensible to do something similar with Code/VSCodium. While working on this I realized there is some overlap with their Dev Containers and am yet to look into if and how one would run those in a similar fashion and if they could be leveraged to the same end
https://github.com/zed-industries/zed/discussions/6659
Where there is a VSCode theme importer for Zed.
And what it does is silently install a Home Brew package and attempt to execute it on your machine.
Only thing i found in your link that mentions this is about VSCode extension [0] - not Zed extension. How is that relevant here?
[0] https://marketplace.visualstudio.com/items?itemName=degreat....
My corpo rejects a lot software, because they do exactly that.
Sorry that we haven't replied to that GitHub issue yet. We try our best to listen to the community (here, on GitHub, on Discord, ...), but we're a small team and, admittedly, it's tricky to keep up with everything.
I agree that we should ask users for consent before downloading language servers (and other executables).
For everybody who's come across the ticket here or on Reddit and hasn't worked with the Zed codebase yet, let me provide some context on how language support is implemented.
In Zed, we have three ways of supporting a language (and its language servers):
1. Extensions that users can install from the `zed-extensions` repository [0]
2. Pre-bundled extensions that ship with the Zed binary, but still need to be installed [1]
3. Built-in language support [2].
For (2) and (3), the code is owned by the Zed team and we make a conscious effort to review contributions from the community in that area.
That code can automatically download language servers, but we try to vet which exact scripts/binaries are downloaded from where. For example: we heavily use rust-analyzer ourselves and keep up to date with its releases, the Go language server `gopls` is downloaded from the Go team using the official `go` tooling, the ESLint language server comes from Microsoft, etc.
For the longest time, we only had built-in language support (3). A couple of months ago, we shipped extensions for Zed (point 1 and 2 above, parts of it described in [3]). The goal was for built-in language support (3) to gradually move to pre-bundled extensions (2) so that users had the ability to choose which ones to install. We did make some progress, but we haven't ported all languages yet.
We're a small team and can only do so many things at once. So after investing quite a bit of time into extensions, we chose to pause that work and invest into other areas for a while (porting Zed to Linux, for example). Once those areas are in a better state, we plan to come back to extensions, build them out some more, and port the remaining languages.
So, TL;DR: we hear you loud and clear. We try to vet things that are currently installed automatically. But we agree that we should ask users whether they want to install arbitrary binaries on their computer. We also plan to transition all language support to manually-installed extensions once we finish other projects.
[0]: https://github.com/zed-industries/extensions
[1]: https://github.com/zed-industries/zed/tree/main/extensions
[2]: https://github.com/zed-industries/zed/tree/main/crates/langu...
It's a new product, which is clearly seeing quick changes every week, so hopeful you'll get to this one soon. The internet will always be extreme around any issue, and make it seem like the end of the world, to those folks, maybe try zed again later? It's still a good editor to keep in mind.
Although one minor thing about this, getting users accustomed to this flow and then later asking for consent might also raise issues, like this one, just with a more "Zed now prompting for every little thing" in future. So might want to keep that in mind.
Loving zed for go development (especially with a decent suite of Vim bindings), just haven't been able to use things like Flutter , due to lack of debug support, which VSCode does quite well (albeit crashes a bunch).
For external projects, users need to trust the project they're pulling down anyway since it's arbitrary code.
That would also help mitigate the risk of supply chain attacks (since versions are pinned and ideally verify package integrity)
If I may offer a small piece of feedback based on your comment here:
Apart from its speed, the single thing I loved about Zed and made it stand out from the likes of vscode, was the built-in language support.
This made for a great first time experience where I didn't have to search and download anything and everything was working out of the box.
In fact it was so good an experience, that when I had to download another thing for terraform support, it struck me as much more annoying than usually
Reading that your plan is to move in the exact opposite direction is disappointing and, I'm sorry to say, I hope it doesn't come to pass.
If you dont have the bandwidth to do things securely dont do them at all.you are asking the devs to wait until you have time to return to it to plug the holes you have opened because you needed a bulletpoint for your release.
and this is not just a lack of time, its your attitude in regard to the devs, see also the optout telemetry for another example of total lack of respect for privacy.