SSH Remoting(zed.dev)
zed.dev
SSH Remoting
https://zed.dev/blog/remote-development
226 comments
I’ve been using Colima to host docker containers and VSCode with devcontainers to do something similar. Being able to spin up a full stack environment on the fly for working is amazing. It may not be as fast as Zed, but it’s a well thought out workflow that’s very reproducible. It’s been a quick workflow to start using, but is still quite flexible.
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.
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 Mitchell intent for his setup to be slightly different than what you described.
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?
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?
I might have implied the wrong thing. I wasn't implying Mitchell should change his use of NixOS. I was relating to the desire for 'best of macOS and best of Linux'. If I was using NixOS I would do that from an Orbstack machine Linux cli, with Zed as my editor, rather than virtualisaing a full X GUI. Everyone will have their own choices of course.
I've always been running a headless Linux VM wherever I do any dev work, Windows or Mac. Works very well.
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.
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.
1oooqooq(2)
Can someone explain. What is the catch ? Zed is worked on by paid employees. So who is the product, how is the money made and is it open source and if so, how much ? (Vscode has strings attached too)
Just interested since building my workflows around a company's products usually ends in tears (figuratively).
Just interested since building my workflows around a company's products usually ends in tears (figuratively).
This is answered in their FAQ: https://zed.dev/faq :
We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:
We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:
Channels and calls
Chat
Channel notesFor a VC-backed company, this will never ever generate enough revenue growth. So, the real answer is: "If all goes well, we will keep raising VC money and get acquired and shutdown / butchered in 5-10 years".
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.
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.
It might happen the way you describe, or, if they get more popular, then may try to think harder and offer more paid options. Now they're in a growth stage - they need to convince the largest possible number of developers they should switch from VS Code, and that is already a difficult task.
I know, this is the standard VC playbook: First growth at all costs to get everyone into the ecosystem, then pull up the net and monetize. The latter phase is usually when all the subscriptions, value-add nag screens, data sharing agreements and other enshittification goodies pop up.
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.
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.
The other option I see is being owned by a behemoth like Microsoft, in VSCode case, who can pay millions per month in engineering salaries and PaaS, while keeping it free.
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.
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.
[deleted]
And while doing this, they fuck the whole market.
Well as an end user this is pretty much OK right, so long as you are aware of the deal? VC funded companies have subsidized and then abandoned a lot of useful OSS code over the years.
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.
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.
They're already laying the groundwork for a rug pull.
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.
https://github.com/zed-industries/zed/pull/11802
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.
https://github.com/zed-industries/zed/pull/11802
No, it's not ok. It fucks the whole market by subsidizing the growth with VC money. Either a big company will buy them, consolidating their power, or they will IPO and the VCs will cash out and let the public bear the cost. It fucks the customers who are not as well-informed about this as you are. In summary, it fucking sucks.
This seems pretty optimistic to me. I can't imagine any company I've worked for paying for those things. Especially because they're only going to be useful if everyone uses Zed which is unlikely.
Indeed seems very uncommon where I am, even the IntelliJ’s are more often pirated than paid for.
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.
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.
You don't need to beat microsoft in order to have a viable business. You just need to get enough market share.
But, you also have to be better than what’s freely available by enough to get someone to pay for it. Having a good product isn’t good enough, you have to be significantly better.
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)
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)
> Free tools tend to win because if a tool costs money, a developer is just as likely to write their own version.
No, free tools win because a proprietary license is a rent-seeking ball and chain on your means of production.
No, free tools win because a proprietary license is a rent-seeking ball and chain on your means of production.
[deleted]
Btw Jetbrains made Webstorm (web editor) and Rider (.NET C#/F#) editor free now for non commercial use.
This might hurt Zed.
https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-ride...
This might hurt Zed.
https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-ride...
Really? I’ve had employers pay for my Jetbrains subscription.
With Jetbrains you're paying for the IDE.
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.
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.
But with Jetbrains products, you pay or the entire software, not just part of it .
Community edition is free, and it’s a sizable chunk of the entire product
The difference is, all the important features are behind a paywall. This will not be the case for Zed it seems.
I have never worked at a place that uses Jetbrains products which does not pay for their premium offering.
I have never worked at a place that uses Jetbrains products which does not pay for their premium offering.
That’s the thing. Whatever editor I finally migrate from neovim to I’ll likely donate to.
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 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.
> Vscode has strings attached too
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.
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.
For what it's worth; Visual Studio Code and VSCode are not the same. VSCode is MIT licensed: https://github.com/microsoft/vscode/blob/main/LICENSE.txt
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.
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.
What I find unfortunate is that VSCode and Visual Studio Code are so conflated. It's Visual Studio Code in the context of features, it's vscode in the context of license and community.
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.
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.
Microsoft are expert at hiding the strings. I prefer obvious strings if there have to be strings attached.
a very important difference is that MS doesn't let you use some of their quite nice language servers unless you're using VS Code, e.g. Pylance: https://github.com/microsoft/pylance-release/issues/483
for this reason, the non-MS-built VS Code isn't equivalent to theirs, regardless of the license of the editor itself.
for this reason, the non-MS-built VS Code isn't equivalent to theirs, regardless of the license of the editor itself.
https://zed.dev/terms has the Zed Editor use license. That’s different from the Zed source code license.
End you’re not allowed to reverse engineer the editor even though it builds from open source. I wonder how much legal reasoning went into that decision. It might be boilerplate, or it might be necessary for some other part of the contract.
I don’t know. Technically, you can clean-room reverse engineer a GPL binary and your resulting code doesn’t have to be GPL. But you could also just build the open source repo and do that. So I don’t know
I would be ready to pay money for Zed, but I'm happy it's all GPL including the dev server (AGPL). Even if this business does not work, we have the code and the community and all parts of the editor available. Thank you for the team for this.
Happy path is Open-Core where all enterprisesque features and plugins are part of a commercial pro model. Unhappy path involves switching licenses sometime later or project simply dying because of ROI.
Yep. Maybe a good copilot written in Rust and tightly integrated into Zed. Offer a subscription model. I'd pay for that.
You are the product. The editor is free afaik, and is very good. It has a plugin system and many languages have been added. It's really, really close to be my replacement to intelliJ. Sadly many bugs are stopping that for now.
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.
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.
I’ll have to give it a look. I’m an increasingly disenchanted IntelliJ customer also.
I assume they did the same as with Rider, and made the UI objectively worse, rather than solve a million other things that actually need improvement (performance!)?
10 years ago, Intellij, 1 IDE to rule them all they said. There are 14-15 at my last count. Complete cash job.
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.
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.
[deleted]
> You are the product.
As far as I can tell from the Zed FAQs and license, this is false.
Can you provide information to support this assertion?
As far as I can tell from the Zed FAQs and license, this is false.
Can you provide information to support this assertion?
That's just the old copypasta:
"If you don't pay for the product, you are the product"
"If you don't pay for the product, you are the product"
>It's really, really close to be my replacement to intelliJ
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.
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.
Wow it still doesn't support debugging it seems.
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.
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.
Zed is closer to VS Code than an ide like intelliJ or text editor like Sublime
[deleted]
Just a FYI, this feature will install a binary on the remote host and run it.
> 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://zed.dev/docs/remote-development
> 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://zed.dev/docs/remote-development
As long as that is notified and correctly authenticated, it is a reasonable approach because the remote process can progress without having to send the whole workspace through SSH. I also expect most language servers would have to be on remote for the same reason.
It's not a reasonable approach because these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
(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.)
(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.)
They address this in the article - they're statically linking with musl, which should address most distros, and their phrasing indicates that they're testing multiple distros too.
> 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.
> 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.
> these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
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.
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.
What a perfect attack vector even if Zed and Vscode people are completely honest
What’s the attack vector? Someone with ssh access to your machine can run code on your machine? That’s part of ssh.
Presumably the attack vector is that someone malicious at Zed or VSCode could change the code in the server components to introduce a backdoor that could be used later.
That's what VS Code does too, BTW.
Microsoft is not the bar for what's a good solution for open source Linux operating systems.
..and is not even open source (EDIT: I'm wrong, see below). Zed's remote server on the other hand seems to be OSS. One could probably install it themselves without relying on the automatic download.
https://github.com/zed-industries/zed/tree/633b665379c18a069...
https://github.com/zed-industries/zed/tree/633b665379c18a069...
? The remote server (reh) is part of the vscode repo itself https://github.com/microsoft/vscode/tree/main/src/vs/server/... there is a vscodium and codeoss builds of it too (reh builds).
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 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.
Hmm, are the docs outdated then or are they talking about something else?
> 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...
> 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...
That’s the extension which launches the server. The server itself, which is what runs on the remote machine, is part of the vscode repo itself. You can see this open source extension for an example of what the extension does as well as an explanation of what it does https://github.com/xaberus/vscode-remote-oss
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.
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.
Thank you for pointing this out.
What’s the resource footprint of that binary?
The VS Code equivalent has been unsuitable for resource-constrained servers in my experience.
The VS Code equivalent has been unsuitable for resource-constrained servers in my experience.
Executing random binaries off the internet is such an annoying "modern" thing. I do not want that, I want to build things from (open source) source.
You can whack Zed in the head by putting in ~/.config/zed/settings.json
It also manages to break the `zed: extensions` page even for already-installed extensions. I sure feel like I'm being the product..
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..
Intellij IDEA does that too, and the installer is a very big file. I suspect an entire headless IDE is installed in the remote host.
That's how most of these remoting features work, by running the IDE backend on the remote host.
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.
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.
Jetbrains provide an option to use their lightweight remote development gateway[1] and not have the IDE installed on the local machine at all.
[1] https://www.jetbrains.com/remote-development/gateway/
[1] https://www.jetbrains.com/remote-development/gateway/
Gateway is just a launcher. It installs the ide both remote and local.
I switched to Zed for C, C++, Rust, Angular, and am extremely happy with it. I use it with it's vim mode, which is very good.
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.
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.
I've been using vim since the 90's, then emacs and helix. Never a GUI editor, always terminal. This year I just tried Zed and I'm super happy about it. It's open source, they offer a flake in their repo for me to get the latest version compiled to my NixOS installations if I want. It's fast, their LLM features are tasteful and they come with the open source version of the editor. It's written in Rust which is my main programming language.
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...
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...
I use vscode (with omnisharp not c# devkit) for c# every day. Did you try it out?
I did not! Rider is extremely satisfying to use.
Is devkit better than Rider ?
I tried to use vscode c# devkit but it is horribly unstable and has severe bugs that make it unusable for my projects. But I'm really happy with vscode + omnisharp. I never used rider so I cannot really say which is better but I tend to not like jetbrains IDEs (from experience with IntelliJ and webstorm).
Caveat emptor: "Zed downloads NodeJS binary and npm packages from Internet without user’s consent"[1]
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.
[1] https://github.com/zed-industries/zed/issues/12589
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.
[1] https://github.com/zed-industries/zed/issues/12589
Oops indeed. (Downloading can be fine in many---but not all---cases, but the lack of authentication is not really justifiable!) The latest comment does hint that it will change in the near future, as the change is required for remote development anyway:
> 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 :)
> 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 :)
I don't see how this is different from having all these pre-bundled with a new version of Zed? Either way I'm going to download all of them again.
By bundling, Zed guarantees or at least claims that those bundled executables can be trusted. The same level of trust is possible with on-demand downloading only when some sort of authentication is used [1] but Zed currently doesn't actually authenticate any downloads to my knowledge.
[1] Either by embedding cryptographic hashes to the distribution, or by having some means to distribute publicly signed hashes (e.g. minisign via HTTPS).
[1] Either by embedding cryptographic hashes to the distribution, or by having some means to distribute publicly signed hashes (e.g. minisign via HTTPS).
>By bundling, Zed guarantees or at least claims that those bundled executables can be trusted
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.
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.
Well, in any case Zed would be morally responsible for that issue or vulnerability, in the way that they have to at least push a new version that fixes it or prevents the download of affected dependencies. (I don't expect any legal responsibility to be clear.) Bundling at least makes Zed more conscious about what to include, even though it is unreasonable to expect that they've checked every details.
What I might trust on my laptop is TOTALLY different from what my company might allow on a remote server.
I also switch between a lot of computers (work computer at home/work computer at work) but have to develop on "big powerful machine at work". My current solution is tmux + nvim and it works really good. I can just pickup a session from whatever computer I'm in front of at the moment.
Am I correct in that neither Zed nor VS Code support this usecase yet?
Am I correct in that neither Zed nor VS Code support this usecase yet?
I use VSCode + SSH remote for this and works great. The only nitpick I have is needing to manually reconnect when I suspend my laptop and ssh connection breaks. It's a separate session though, which doesn't matter to me but may be a deal breaker for you.
I use Tailscale for a personal VPN so the beefy workstation is always securely available from my laptop, even when across the pond).
I use Tailscale for a personal VPN so the beefy workstation is always securely available from my laptop, even when across the pond).
Thank you both for sharing the experience.
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.
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.
There's no input delay in VSCode (editor, ui) because the UI is local. Delay in saving/reading/sesrching in files is not noticable for me.
(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.
(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.
Thank you. Sounds like best of both worlds.
Do you get used to the input delay?
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.
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.
I guess editing files in the same continent must feel good enough.
Thank you! I should try a project in this way.
Perhaps rent some hetzner VPS.
Thank you! I should try a project in this way.
Perhaps rent some hetzner VPS.
10 years ago I was using https://mosh.org/ to sutomatically reconnect ssh sessions.
VSCode uses ordinary ssh tho.
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.
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.
AutoSSH has been doing that since forever too (in most distros, ie apt-get install autossh)
https://github.com/Autossh/autossh
https://github.com/Autossh/autossh
There's also `et`: https://mistertea.github.io/EternalTerminal/
Not persistent sessions, but VS Code can run the GUI locally and connect to a remote server. When you reconnect it opens all your tabs, workspace settings etc.
How are people so happy with Zed? I've tried it, it's fast sure, but it lacks some very essential features like inline error highlighting and button for running code like how Intellij has it, there is no extensions that cover this either.
At the moment, the Zed IDE is more like an lightweight ai-assisted text editor for me.
At the moment, the Zed IDE is more like an lightweight ai-assisted text editor for me.
I think that is precisely why people, and myself, ate happy with Zed. I don't, personally, care for those kinds of features. I want something that is snappy, and bloat free. I beloved extensions are planned so that will come in time. I'm terms of inline error highlighting, it absolutely has that. is your LSP just not working correctly?
> is your LSP just not working correctly?
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.
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.
I wonder if image based screen sharing (e.g. Google Meet) is the "worse is better" here?
Zed collaboration sounds great, but what about all of the other apps I use?
Image based sharing supports everything (poorly) automatically.
Zed collaboration sounds great, but what about all of the other apps I use?
Image based sharing supports everything (poorly) automatically.
I'd really like a good remote editing solution that is genuinely portable. I don't think there's anything technical stopping that from happening (and I've tried some half baked solutions along those lines before).
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.
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.
I'm going the container route. To get the full seamlessness you're alluding to (easily switch between multiple parallel environments; easy migrations) still requires some additional features but perhaps you can find some inspiration.
https://github.com/legobeat/l7-devenv
E.g.
https://github.com/legobeat/l7-devenv/pull/144
https://github.com/legobeat/l7-devenv/pull/153
https://github.com/legobeat/l7-devenv
E.g.
https://github.com/legobeat/l7-devenv/pull/144
https://github.com/legobeat/l7-devenv/pull/153
Although I don't understand why you would still want to do that with modern processes, configuration management, CICD tools and the decentralization of git, you can just mount the remote directory via ssh.
People have been doing that for decades already. Works with any editor/ide/tool.
People have been doing that for decades already. Works with any editor/ide/tool.
[deleted]
I guess the reason to run the IDE on the server is so that the IDE can inspect the whole (potentially huge) codebase and provide LSP features like code completion & go-to definition, and AI assistance.
I can find no mention of Emacs (or Tramp) in any of the documentation or a sampling of blog posts. It’s as if the authors don’t even know it exists. This is concerning.
(As is their apparent 100% all-in on the AI hype train.)
(As is their apparent 100% all-in on the AI hype train.)
Yep. Emacs had this 25 years ago. I find editing over SSH a last resort, though, as it introduces a lot of undesirable latency.
>I find editing over SSH a last resort, though, as it introduces a lot of undesirable latency.
I suggest you give Zed a try then or even VS Code remote, just to compare. They're much better engineered than Emacs tramp.
I suggest you give Zed a try then or even VS Code remote, just to compare. They're much better engineered than Emacs tramp.
Emacs had this 40 years ago. ;-)
I'm not surprised! I said 25 because the TRAMP manual says (c) 1999.
Before there was Tramp, there was AngeFTP.
Personally, I need support for remote debuggers, e.g. debugpy on Python. Would this feature help me debug code that's already running on a remote server and I just need to connect to it?
I really wish there was a good alternative to vscode for remote debugpy
Same. I don't like VSCode, but debugpy is, for me, a killer feature for which I'd pay if I had to.
I was told that pythons repl was equivalent or as good as Common Lisp/Clojure, and it doesn't even look like it has a networked repl without third party code.
I now wonder if pythons repl experience isnt even close to lisp likes.
I now wonder if pythons repl experience isnt even close to lisp likes.
I tried to use zeds SSH remoting for a work project. Typescript with big codebase and sadly the performance is a rollercoaster. Types sometimes load so slow that it's unusable. VSCode remote doesn't seem to have this problem, although I'm not sure yet if it's really just a zed problem. I would need to try it with some more isolated use-case. Still happy to see the progress! I switched to zed for a lot of my private dev work already
I tried to use Zed but the text rendering on macOS was so painful that I didn't get far. Hopefully they'll address so I can give it another go in the future.
What’s the issue exactly? I’ve been using it on macOS for a few months now and while it has its issues, text rendering hasn’t been one of them.
Text looks very blurry when compared to Sublime Text with the same font family and size. There's an active issue about it on GitHub with screenshots.
https://github.com/zed-industries/zed/issues/7992
https://github.com/zed-industries/zed/issues/7992
Such is life using macos on low dpi screen. A lot of apps render blurry texts :(
It was definitely a lot worse than any other application I use on a 1440p 27-inch screen.
How's Zed with WSL (now)? I've liked the ability to run the VS Code back-end in WSL and front-end in Windows, is this possible with Zed?
I wouldn't go there. These things are supposed to be helpful, any bug or chance of a bug will be detrimental to their stated purpose, just imagine scenarios were zed tells git to download a repo and you have to make sure it downloads to a linux directory and not a windows directory, otherwise you lose all of the access bits, and it's slow af.
Asking for trouble.
Asking for trouble.
I appreciate your concern and I will consider this.
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.
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.
Zed still doesn't have Windows version (but someone is working on it), so currently no.
Someone reinvented tramp-mode.
I suggest you try it and compare it to tramp-mode and see for yourself how different it is(and just how much better it is to tramp-mode)
This appears to be a significantly better implementation. Tramp mode is god awful slow and does not maintain a persistent connection.
The default setup is pretty crappy but with some tweaking of the ssh connection setup, It does a decent job and I used it for actual work for several years.
Would you mind outlining the settings or pointing to a reference?
It's been a long time. Most of the stuff I was able to get from conversations on the Emacs IRC channel of freenode. Many of those "tricks" are documented here https://www.emacswiki.org/emacs/TrampMode but I don't know if it's out of date.
I recently tried to use SSH remote editing with VSCode on a plane. It is so incredibly chatty that the in-flight wifi system thought I was trying to tunnel traffic via SSH and kept killing the connection.
I hope the Zed developers have taken bandwidth minimization into account.
I hope the Zed developers have taken bandwidth minimization into account.
You were tunneling traffic through SSH :P
Afaik the problem are big file directories, at least that what I noticed.
"the language server is continually out of memory"
"8gb is enough for everybody"
"8gb is enough for everybody"
I want to like Zed but two things are still an issue for me:
- 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
- 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
Also works well in vscode. Just wish the remote instance would keep running forever. Currently it's only a few hours it seems. Then one needs to reopen the workspace window.
I don't use code editors, but when we had an issue with ssh sessions hanging, it was always coworkers that were using vscode and connecting something up with that.
Man, just ssh through the terminal like a normal person and transfer files with git.
Man, just ssh through the terminal like a normal person and transfer files with git.
"Man, just put it on tape and walk over to that machine to load it there".
Sorry, I know such low-effort puns are shunned on HN, but once in a decade I grant myself the permission to not resist.
Sorry, I know such low-effort puns are shunned on HN, but once in a decade I grant myself the permission to not resist.
Given my experience with the vscode remote instance, that actually sounds terrible as it can get bloated very quickly. The instance state can and should be retained without running the instance indefinitely.
I cant wait to switch to something like Zed. VS Code can take up half of my memory and keeps crashing after updates. How much language support is there for Go?
It has built-in support for Go: https://zed.dev/docs/languages/go
I switched from Goland to Zed. Works really well. Only missing debugger support... After that it would be perfect for my usage :)
A nice setup for Rust development where compile times are high. You can offload that to a beefy machine while using the editor on a MacBook Air :-)
There was discussion about Zed over at Lobste.rs ~9 months ago when it went open source. I tried it then (as it was compared a lot to VSCode or Visual Studio code, which according to comments here are two separate things, to my surprise?) and I just updated and tried it again, and my initial feeling about it is unchanged:
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.
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.
Has anyone tried this and ssh'd into a container?
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
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'd really like to see this. I already run a bunch of containers on servers at home and work, and running a "Zed server" of some sort would be fabulous.
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?
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?
I just connected from VS Code running on Windows to a devcontainer running on a Steam Deck
I'm not familiar with devcontainers. The situation I was curious about was a general container, for example singularity, rather than something more common like docker. When I've tried that with vscode, it didn't like the ssh config that allowed you to ssh into the container and wouldn't work, even though in a bash shell it worked exactly as advertised.
[deleted]
Any chance for a iPadOS release?
I wish I would be able to start a dedicated server that could then be joined by both myself and my co-workers to work together.
From reading the article, it seems that collaboration is a wholly different layer, just like in VS Code.
From reading the article, it seems that collaboration is a wholly different layer, just like in VS Code.
I have been using code server over ssh for this purpose for years.
How’s this different from starting tmux session on a remote server and editing code with a text editor and running in that session? Is Zed not a terminal text editor?
Zed is a GUI code editor. Also the difference is where the UI runs. Running the UI locally gives much better response and lower latency than running the UI remote.
I would switch over to Zed for all my non-JVM needs if only it would have a debugger support. Currently it's filling a role of a text editor pretty well though.
Is somewhere a comparison of Zed to Visual Studio Code?
for a start, zed doesn't work on Windows. I'm not exactly a fan of MSFT but at work, I must use Windows...
It does work.
Automated builds are here: https://github.com/deevus/zed-windows-builds
Automated builds are here: https://github.com/deevus/zed-windows-builds
Builds are there, but they don't work. At least on my laptop.
Memory footprint, startup times, overall responsiveness. At the end of the day VSCode is still Electron app.
In my experience, the electron overhead is relatively negligible compared to the ressource usage of the language servers. And zed seems to use the same language servers.
It is certainly true that the language servers have the same speed in Zed, but there is something to be said for just never suffering from any UI delay for any reason.
Though I'll admit a LS that takes three seconds to respond is kinda indistinguishable from UI delay.
Though I'll admit a LS that takes three seconds to respond is kinda indistinguishable from UI delay.
What kind of codebases do you work with? Other than with multi-MB files or thousands of multi-cursors, I've never had any performance issues with VS-Code. It's actually one of the fastest Electron apps, I would say. If I notice a delay, it's usually the language server or some support package's background command taking a bit of time.
If all you know is VS Code it probably feels fine and you should definitely not try Zed - "one of the fastest Electron apps" isn't exactly a ringing endorsement.
I have used both unbearably slow IDEs like Visual Studio, Android Studio, Atmel Studio and very fast and lightweight editors like Notepad++ and Sublime Text.
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.
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.
Sublime is faster still. If speed is your main concern.
How old is your computer? Some people have longer upgrade cycles than others.
Granted, all of my machines are pretty new and powerful.
Maybe performance is a lot worse on >5yo machines.
Maybe performance is a lot worse on >5yo machines.
I remember that my computer in 2016 was already fast enough.
How does LSP affect the core editing functionality like "startup times, overall responsiveness"?
VSCode does not necessarily require Electron.
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.
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.
Main and often repeated argument against Electron is that it has a browser embedded inside, and that's why it's so bloated, slow and taking up so much memory.
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?
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?
Glad to see this. It's probably one of the biggest features in vs code that I find indispensable along with the integrated terminal.
Will give Zed a try now.
Will give Zed a try now.
Used Zed for a week or so, loved it! But the lack of mypy / git integrations forced me back to VS-code :'(
I switch between Sublime and Zed all day depending on what task I'm doing, some things it's still not quite as good at as Sublime. The Ruff integration is excellent though, and the good news there is that apparently they're working on a type checker for Ruff's language server.
Yeah, while I'm pretty happy with git in the terminal, I'm eager to see what Zed's take on a git workflow will look like. The inline git blame info is nice, but a UI for committing and push/pulling the repo would be great.
with a little bit of work, vi/emacs works great as an IDE for most setups... The learning curve is steep but once you get the gist, you never go back to those bloated IDEs.
(Disclaimer: I haven't tried zed, but have been working throughout my career with Eclipse, Visual C/C++/Basic (!), Atom)
(Disclaimer: I haven't tried zed, but have been working throughout my career with Eclipse, Visual C/C++/Basic (!), Atom)
Unless you need a graphical debugger, then vi/vim/nvim/emacs all start to get creaky. That single requirement keeps me on vscode. I'd love a terminal based alternative.
Graphical as in integrated with the normal editing view? There's a new very nicely done one for Emacs: https://github.com/svaante/dape . The documentation about using it is currently a bit terse though.
I actually don't mind if it's not integrated with the editor. I'm fine with a debugger being a standalone application. What I want is the ability to see the source, set breakpoints and navigate the code efficiently inside the debugger. vscode is currently the best option for this remotely
just don't write buggy code ;) (or have to work on anyone else's)
> The learning curve is steep
So it's not "a little bit of work"
So it's not "a little bit of work"
Compared to mastering C++, vim is a piece of cake.
For me it was a major productivity boost.
Try remote development with vim over 200ms ping ssh connection
I've tried that, but in this case i would just NFS/sshfs share the directory and work with vim locally.
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.
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.
>Try remote development with vim over 200ms ping ssh connection
Isn't such a scenario (high latency dialup) what vi was originally designed for?
Isn't such a scenario (high latency dialup) what vi was originally designed for?
I have frequently done full vim editing on primary development boxes across cross-Atlantic pipes, which are usually 150ms from where I am in the states. Not really a bad experience in any way, tbh. I'm sure my tolerance level would decrease dramatically at 300ms though.
Zed is great. But as long as they don’t support eslint properly, it’s a turn down for me and my organization.
How does this compare to vim over mosh?
Is that similar to webstorm's remote development?
Running an unknown app on a trusted remote server under your local user account - not a good idea! Just keep it local on your own machine.
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.
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.
I guess the reason to run the IDE on the server is so that the IDE can inspect the whole (potentially huge) codebase and provide LSP features like code completion & go-to definition, and AI assistance etc.
Wow, this is some incredible technology. It's not like tmux and neovim have been available for a decade now. This is like space-age alien technology with which, for the first time ever, we can develop over ssh!
What a world we live in, what a time to be alive!
What a world we live in, what a time to be alive!
Those who do not understand Emacs are doomed to repeat it. Poorly, in worse languages. —C.S. Santayana
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.
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.
Don't many editors have the feature of allowing remote editing through ssh?
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.
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.
Addendum: in retrospect, I do regret my dismissive tone. It wasn’t terribly nice. I’m sure that the developers of the feature are very proud of it, and justifiably so. All the best to them.
I still maintain that it’s a pity they don’t invest their efforts in Emacs, but … it’s a free world!
I still maintain that it’s a pity they don’t invest their efforts in Emacs, but … it’s a free world!
Fun fact. Emacs was doing this even long before Tramp, in the 1980s it was already common to work with remote files. So more like 40 years …
What's the point of this comment? Zed didn't exist in 1998, so I think it's forgivable that Zed didn't support remote editing in 1998.
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.
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.
> What's the point of this comment?
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?
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?
Vscode's remote SSH is much better than tramp mode imo. They are not really on the same level.
"Just" does quite a bit of heavy lifting here. VSCode and Zed are much easier to use than emacs or vim. To me as a user, emacs lisp (and lisp in general) is the worse language compared to TypeScript which I can work with.
> VSCode and Zed are much easier to use than emacs or vim.
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.
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.
Jetbrains Gateway also does this.
I've tried zed again and it's kinda "meh" when it comes to Java development. It's kinda nice editor (but BBedit feels even faster) but nothing more and using it feels like an added friction...
this is cool, love it.
make windows here before doing ssh?
why is there so much hype about yet another editor?
"So much hype" being defined as "the ocassional release announcement HN post now and then", most of which could be submitted by Zed themselves?
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?
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?
If we all stuck to the first thing that worked and searched for no improvements whatsoever, we'd all be riding horses.
[deleted]
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