"8gb is enough for everybody"
Automated builds are here: https://github.com/deevus/zed-windows-builds
Though I'll admit a LS that takes three seconds to respond is kinda indistinguishable from UI delay.
Maybe performance is a lot worse on >5yo machines.
I don't have any issue with the speed of VS-Code on my machine and it feels the same as Sublime Text used to.
Unlike Zed, VSCode can actually run on a server, and Google Chrome can be used as a client.
You can even take advantage of all VSCode features and plugins using Google Chrome Mobile.
Yet you give counterexample of using... a browser as a client/frontend to vscode. Well it doesn't remove the exact main problem with Electron, does it?
Man, just ssh through the terminal like a normal person and transfer files with git.
Sorry, I know such low-effort puns are shunned on HN, but once in a decade I grant myself the permission to not resist.
Am I correct in that neither Zed nor VS Code support this usecase yet?
I use Tailscale for a personal VPN so the beefy workstation is always securely available from my laptop, even when across the pond).
I'm tempted to go lightweight laptop + beef server.
Do you get used to the the input delay? I guess coding is not a FPS game so it's fine. Just a flow of words being edited.
The input delays are very dependent on where the server is and what it is doing. If the server is idle and close by (ping wise) delay is virtually indistinguishable from local VSCode. If I'm connecting to the server via a VPN in a different country while stressing all the cores with some background compiling or number crunching work, input delay gets quite noticeable.
Thank you! I should try a project in this way.
Perhaps rent some hetzner VPS.
(edit to explain: VSCode is still running locally, but it also installs the server-side (headless) component on the remote machine. That way editing files is local/fast, but stuff like running the code, search/replace/etc also works fadt because it's handled by the serverside).
Terminal (incl vscode terminal) feels slightly sluggish, and it's noticable if the server is in another country and uncomfortable if across the pond.
I multiplex my ssh connections so the workflow is just ssh sgain, then reload VSCode window. If Mosh could multiplex these (and paper over the connection problems) that'd be great but after a cursory look, it doesn't look like it's possible.
It's a minor thing tho.
In general, I quite like Mosh! If I routinely had to work on faraway servers I'd use mosh just for its smart local echo.
This has been an open issue for 5 months. When I noticed it, I couldn't believe my eyes and it was the last time I've run Zed so far. Judge for yourself whether this is a deal-breaker for you; I wish I had known about it earlier.
> Status update: We are still working on this! The major blocker is that extensions have not been setup to interact with setting. However, we also need to change this API to support our upcoming remote development feature. So we're going to roll both of these breaking changes into a larger extension update, coming this November or December :)
[1] Either by embedding cryptographic hashes to the distribution, or by having some means to distribute publicly signed hashes (e.g. minisign via HTTPS).
As if anyone at Zed cares and checks them all thoroughly? Even if they wanted they couldn't, given how expansive Node dependencies get.
At best, someone will report an issue/vulnerability for one of those to them. Usually months/years after it exists.
For the record, I've tried the JetBrains suite for at least a year, vscode, vim, neovim, visual studio (windows), qtcreator, and at least one more I dont remember. Zed is superior for everyday coding, for me.
The only thing it lacks is debugging, so I can't use it for C#, but I also can't use vscode for C# so that's understandable.
And man, its so snappy.
This SSH feature is great, I can just remotely turn on my workstation at home and use it with Zed over tailscale.
I'm also waiting for a good debugger story, especially for Rust. It will come...
Asking for trouble.
The [VS Code] WSL back-end has access to things in WSL PATH, like compilers and language servers. I don't duplicate them in Windows, and would like to avoid having double installs. It's also nice to be able to open integrated terminal and use `fish` and other unix-only CLI utilities.
> Your local machine will attempt to connect to the remote server using the ssh binary on your path. Assuming the connection is successful, Zed will download the server on the remote host and start it.
https://github.com/zed-industries/zed/tree/633b665379c18a069...
The extension that invokes it isn’t, but there are a few implementations of it that are, and I think vscodium bundles one with their build. It’s just some shell scripts that download the reh build and run it with the correct args.
> The Visual Studio Code Remote Development extensions and their related components use an open planning, issue, and feature request process, but are not currently open source.
https://code.visualstudio.com/docs/remote/faq#_why-arent-the...
Mainly just sets up the UI/connect commands in vscode UI and launched REH (the vscode server) on the remote machine. The actual server is just a different binary you build from the same repo. Non-Microsoft OSS builds of vscode work with SSH fine.
I'm not sure if IntelliJ IDEA has an equivalent, but CLion has an option to just do the build and run/debug on the remote host without running the whole IDE on it.
(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)
Whoever makes publicly available binary blobs are necessarily aware of all those issues and try to engineer them to be resilient enough for most environments. That's why they typically work well even though they generally have little information about the system besides from most basic ones (ISA, OS/kernel and ABI to be precise). This is significantly more difficult in Linux due to its higher variability, but not even close to impossible.
> Unlike our normal Linux builds, the remote server can be compiled with musl, which requires no dynamic linking. This lets it work on older distros (where before we ran into compatibility problems with glibc) and on modern share-nothing distros like Nix that don't have a global set of libraries to dynamically link.
The VS Code equivalent has been unsuitable for resource-constrained servers in my experience.
You can whack Zed in the head by putting in ~/.config/zed/settings.json
"server_url": "https://disable-stupid-crap.zed.invalid",
It also manages to break the `zed: extensions` page even for already-installed extensions. I sure feel like I'm being the product..
(Disclaimer: I haven't tried zed, but have been working throughout my career with Eclipse, Visual C/C++/Basic (!), Atom)
Vim can also read and write files across networks (while running locally): vim scp://user@myserver[:port]//path/to/file.txt should work.
If you want to run builds and such on a terminal, just have a tmux window with an active ssh connection.
There's a solution to most issues out there.
Isn't such a scenario (high latency dialup) what vi was originally designed for?
So it's not "a little bit of work"
I hope the Zed developers have taken bandwidth minimization into account.
I can now spin up a Linux machine in Orbstack[0] in a few seconds and then SSH into it from Zed for a fast Linux development environment with a fast macOS native editor. It feels a bit like the macOS version of WSL and VSCode. Just a whole lot nicer (subjective of course)!
A couple of years ago I was inspired by what Mitchell Hashimoto was doing[1]. He was running a GUI VM via VMware on macOS so that he could have the best of both worlds - macOS apps and ecosystem and a Linux dev environment with his preferred package managers and a more reliable NixOS. That route still felt a bit heavy to me, but I related to the desire for the best of macOS and the best of Linux.
I tried with VMware and Docker Desktop with VSCode but it always felt like a lot of overhead and a bit clunky to achieve a smooth fast dev environment.
With Zed and Orbstack it finally feels like the fast elegant system I'll stick with. Thank you to the developers for these excellent tools!
[0] https://docs.orbstack.dev/architecture#linux-machines [1] https://x.com/mitchellh/status/1346136404682625024
Glad to see that WSL2 and OrbStack promotes this workflow.
For now my only complaint is I prefer full-blown VMs instead of WSL-like setup (so that I can work with the same Linux kernel my code targets), but client virtualization support on Apple platforms are pretty meh, definitely not at Hyper-V level yet. OrbStack went out of their way to fix a lot of these but they are not interested in making a VM product.
Regardless of which stack you use, I think this is a great style of working. When you have a reproducible dev environment, everything is so much easier. (As vagrant users will probably attest to - it’s not a new method).
But having this feature of SSH remoting is also quite handy without the dev environment stack stuff. I also find it quite nice to work with a local client, but remote SSH environment when I’m doing data work (large genomic data files). In this case, instead of reproducibly, the main benefit is data locality. If my large dataset is on a different server, it’s far more convenient to write the analysis code on that remote server. This new Zed feature seems like it will also support this workflow, which is also a win in my book.
I understood it as him running Nixos/nix because it made having a reproducible development setup a breeze since it’s all just a config file.
How would his use of Nixos change as you imply with Zed/SSH?
For a variety of reasons relating to my line of work, this or vscode's solution are no gos since they require you to install a server on the remote, and that server is interpreted or compiled in a language that is absolutely not guaranteed to be present or stable on said remote (I'm saying my ideal extension, if a server is really necessary, would be in a reasonably widespread subset of C, perhaps ISO c99, which I'm sure I'll catch some flack for saying).
That is an underserved (although perhaps not large, but probably they would be enthusiastic) market given that remote editing is perhaps the most useful in situations where the remote environment is different to such an extent you can't easily copy a project over and expect it to just work. If I'm deploying to an x86_ 64 Linux box, I can totally just develop locally and do a lot of testing locally deploy to the remote after all of that, and so I tend not to get too excited about remote editing features for a platform like a normal x86_64 Linux distro.
I'm obviously being picky and demanding and people are free to ignore everything I just wrote. As far as Zed is concerned, the editor looks good and this functionality looks good and I'm happy to see it moving along. Please forgive me for indulging my personal pet peeve. It is a good thing by itself to have competition to vscode and so please don't interpret my post as being overly negative to Zed given it's main competitor has the same issue.
Also, I'm aware that a fair response to everything I just wrote would be "just use vi/vim/emacs"...which is actually really fair and does a lot to demolish my argument, at least as far as a remote editor being a necessity is concerned rather than just a nice to have.
People have been doing that for decades already. Works with any editor/ide/tool.
https://github.com/legobeat/l7-devenv
E.g.
Just interested since building my workflows around a company's products usually ends in tears (figuratively).
They'll charge for integrations later, collaboration etc. I'm not sure exactly where the money is going to come from but I value a quality native IDE.
I hope they don't stuff crap down our mouth in the future and simply charge a one time fee per version. But that of course is unlikely to happen.
Every new version of IntelliJ I gasp that they F'd with something, and usually I'm right.
Bugs I reported went unanswered for 3 years and then swept under the carpet, still not fixed. Obvious stuff too. Breaking and annoying stuff.
The best part was when they came out and claimed they had the best latency to screen rendering, long article explaining the technology etc. behind it. Mac just came out with retina screen, and their stuff is written in Java, did not handle any kind of graphics acceleration. It was a complete joke, just pressing 'aaaaaaaaaaa' on the keyboard would start lagging after 10 characters to seconds long to render. Insanely funny stuff. If you shrank the IDE to 1/4 of the screen it was much faster! yay.
I stopped paying a little while back and jumped on the community edition for debugging and other IDEs to write the code. I'm sick of their antics.
Isn't Zed just a text editor? The last time I checked it out it didn't have any debugging features which doesn't really make it a replacement for an IntelliJ IDE.
https://github.com/zed-industries/zed/issues/5065
People who use Zed now at work, sorry but you still print variables to debug issues? In 2024?
Zed is investing in features to satisfy shareholders like AI and team collab but ignoring a basic functionality like interactive debugging is mind blowing.
As far as I can tell from the Zed FAQs and license, this is false.
Can you provide information to support this assertion?
"If you don't pay for the product, you are the product"
We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:
Channels and calls
Chat
Channel notesI have never worked at a place that uses Jetbrains products which does not pay for their premium offering.
Zed's vision is that the editor is free and you're paying basically for Teams-lite.
If you're a big company, you're already using a service like Teams, Slack, Zoom, etc.
If you're a small company, then there's free alternatives like Discord.
And say you want to talk to someone other than a programmer, then you'd need something else anyway. Because a project manager wouldn't need an IDE installed.
From my perspective it is very weird to expect to beat MS (who produces two great IDE’s, not one) on their own game with this approach to dev.
I’m not saying it’s impossible to have the most important features replicated, but, c’mon, this is software, it breaks as it builds and some things are not possible Overnight even if you have the worlds top top top talent around.
Dev tooling is a notoriously difficult space to make money. Free tools tend to win because if a tool costs money, a developer is just as likely to write their own version. (For better or worse)
No, free tools win because a proprietary license is a rent-seeking ball and chain on your means of production.
This might hurt Zed.
https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-ride...
I get so much insane value from open source and companies building for the platforms that I use that I’m happy to pay for them especially for small shops of really passionate hackers like the folks behind Zed.
I don't have much hope in anything replacing it for me. Zed does a lot right but feels very very far away and with a weird focus (from my perspective).
Like Bluesky, this monetization plan they present is just something to calm down the haters and sceptics. But if you think for two seconds, it does not make sense.
And how would it work otherwise? You can't perpetually offer a product for free (in all senses of the word) AND satisfy exponential ROI expectations at the same time.
If this is what's going on here, I'm worried what the "monetization" phase will entail.
They are so big they can monetize it using Copilot or not even monetize it properly, just to get good faith from Developers, Developers, Developers.
I like it.
But no need to discard VSCode.
They are different tools anyway.
Whenever you encounter a VC backed open source project you know the rug pull will come eventually. It doesn't make the code they have written any less useful. If the tool is good enough then it will be forked and live on.
The fact that the developers will happy let you hide any button in the UI except the sign in button is a giant red flag.
If software being FLOSS is in any way an important value of yours, the difference between Zed and Visual Studio Code is night and day:
Zed's GPL: https://github.com/zed-industries/zed/blob/main/LICENSE-GPL MS Visual Studio Code's license: https://code.visualstudio.com/license
I believe this alone shows much more good will towards developers and much less strings attached.
From vscodium.com:
Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking. According to this comment from a Visual Studio Code maintainer:
When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license.
When you clone and build from the vscode repo, none of these endpoints are configured in the default product.json. Therefore, you generate a “clean” build, without the Microsoft customizations, which is by default licensed under the MIT license
The VSCodium project exists so that you don’t have to download+build from source. [VSCodium] includes special build scripts that clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries for you to GitHub releases. These binaries are licensed under the MIT license. Telemetry is disabled.
In this sense Zed is much cleaner as to what's up for for monetization. You look at the project and you know which parts will be candidates for business growth and which parts will stay in the community. With Visual Studio Code, the entire editor is game for monetization and utilization for Microsofts business goals, yet has the appearance of open source and community owned.
for this reason, the non-MS-built VS Code isn't equivalent to theirs, regardless of the license of the editor itself.
I now wonder if pythons repl experience isnt even close to lisp likes.
Zed collaboration sounds great, but what about all of the other apps I use?
Image based sharing supports everything (poorly) automatically.
(As is their apparent 100% all-in on the AI hype train.)
I suggest you give Zed a try then or even VS Code remote, just to compare. They're much better engineered than Emacs tramp.
And "yet another editor" as in implying that all editors edit, so Vim or Emacs or VSCode or Zed or whatever shouldn't matter, as none brings anything different/new to the table?
From reading the article, it seems that collaboration is a wholly different layer, just like in VS Code.
IIRC VSCode struggled to correctly ssh into a container that's set up in your `.ssh` config file. Not sure if this fixed it: https://github.com/microsoft/vscode/issues/194879
I also wonder (I haven't looked yet) how Zed communicates with its server process over SSH, and if this could be accomplished over some other protocol. Is it possible SSH could be a speed (or latency) bottleneck on high-speed networks?
- Zed doesn't know how to highlight XML - I use a theme called FairyFloss which doesn't exist for Zed and Zed doesn't provide anything to import VSCode themes
Will give Zed a try now.
Emacs TRAMP mode has been doing this for 26 years, since November 1998. Fashions come, and fashions go, and Emacs remains. Anyone remember Atom? Anyone remember TextMate?
Just use vi or Emacs.
False. It's just that Emacs comes with fewer features out of the box.
> emacs lisp (and lisp in general) is the worse language compared to TypeScript
Elisp is truly a piece of shit language, but TypeScript is not much better.
It's pretty funny you'd comment this at the same time there's a thread on the front page with people complaining about emacs bugs/performance issues: https://news.ycombinator.com/item?id=41954030
Is that really the best we can do? Should we have frozen tech in 1998 with our 28.8kbps modems and stopped trying to improve anything ever again? Why did you switch to this emacs fad when you could have stuck with ed(1)?
I think it's great that people are advancing the state of the art. Good for Zed.
To encourage people to use Emacs (or vi).
> Should we have frozen tech in 1998 with our 28.8kbps modems
We had Ethernet and high-speed networks in 1998. The rest of the world has just caught up, that’s all.
> Why did you switch to this emacs fad when you could have stuck with ed(1)?
Emacs is an improvement over and above vi & ed. No other current editor is an improvement over and above Emacs. The only improvement Emacs is lacking is Common Lisp extensibility.
> I think it's great that people are advancing the state of the art.
But they’re not — they’re reimplementing the decades-old art. Why waste time using worse technologies to extend worse editors when one can invest one’s time using better technology to extend a better editor?
There was discussion here a few days ago for example of an Acme clone named Anvil, which has the feature, as does Acme.
VSCode has it.
Also, TRAMP is a poor (unreliable, fragile) implementation of the feature. Or at least it was the last time I used it regularly about 10 years ago.
Finally, if you have to resort to quoting a slogan then it is probably better not to comment at all.
I still maintain that it’s a pity they don’t invest their efforts in Emacs, but … it’s a free world!
Something about the UI is just... off. I don't know what it is exactly, but it feels like one of those "web page trying to mimic a desktop environment" demos that were all the rage 15-20 years ago.
It's bizarre to think that IntelliJ, which is a JVM app, feels way more 'native' on macOS than Zed.
At the moment, the Zed IDE is more like an lightweight ai-assisted text editor for me.
I don't know, I can't tell, but I would guess it does not. I just got the one and only Java extension there is (the other has has something to do with Eclipse). Yet, no error highlighting.
Your editor can handle everything way faster locally, plus it can grab files with SSH’s built-in (and mature to the point of being ancient!) capabilities: caching, compression, and instant text file downloads over an open connection. You can even check for remote file changes using stat.
Even better, use sshfs or another FUSE option.
There’s a ton you can do with plain SSH alone. This whole running-a-remote-server idea is, frankly, puzzling.
What a world we live in, what a time to be alive!