There's a ton of really good Rust content on the Zed blog. As somebody new to Rust, I've learned a lot from it. For example, how they do ownership in a GUI setting, in a language for which even writing a doubly-linked list is a challenge:
This was a really neat dive into GPUI. The discussion about main thread vs background thread was interesting, especially as it relates to choices the rest of the async ecosystem has made.
Erased? On the contrary it seems, to me at least, like new editor development has really grown over the last few years. Editors like Kakoune, Helix, Micro are coming along nicely. I'm looking to switch, at least partially, to Helix soon myself.
Presumably speed is an overall important factor for the creators — not just startup speed — and I'd imagine it translates into speed elsewhere, such as input latency and UI responsiveness.
Is raw code output so large that your editor can't "keep up" really something to optimize for? For me personally I write as little code as possible. you don't get bonus points for number of lines you write.
Yes, while at the same time having a responsive UI is important for editing, and we're not hanging less stuff in our editors than yesterday. Both emacs and neovim and vscode are essentially IDEs today.
Yes it is, especially when you work with lots of large files in big codebases. I can open files in Vim that would crash VSCode, which is essentially why I still use Vim for certain parts of development.
If this happens with Zed 0.129 or later, could you open an issue? We had a problem at one point where there was a delay in macOS verifying our app’s code signature because we weren’t attaching the code signature correctly.
Their plan is to make really elegant team-based shared coding features baked right into the editor - think a mashup of VSCode + Slack, and then charge for that, likely as a monthly subscription. It's not a bad idea if it can increase team velocity but the requirement would be enough people on the team live within it to justify the cost.
I drove Zed for about a month, its very performant and a joy to use, but the lack of a remote development feature is massively prohibitive and I went back to VSCode as a result.
There are way too many other features missing as well to do anything serious to be fair.
All the things you would like proper IDE to do to increase your productivity.
Let's see in couple years.
The biggest problem is to get those initial features decent so that you can extract the value from crowdsourcing the missing things like VSCode does.
> crowdsourcing the missing things like VSCode does.
Based on what I am seeing right now [1], they might well have enough inertia to seriously compete against VSCode. I've analyzed a lot of open source projects and their community engagement on GitHub is quite impressive. Their contributor and new contributor stats is still going up, even though the initial hype was 2 months ago, which is really impressive.
If they can get proper support for Linux and Windows and nail core features, I can see people wanting to contribute in the future and business leaders paying for it, if they can demonstrate improved productivity and collaboration.
Not the OP, but what I assume they are referring to is the ability to work on a remote host. For example if I have a Mac but I am working on a remote Linux box, VSCode will allow me to easily work sync with a repo on the remote host. It will also seamlessly handle port-forwarding for web dev.
It installs and runs a server stub over SSH (or into docker, or WSL), which lets it act as if you're working on a local project. Stuff like the built-in terminal is remote, building, debugging, etc all work remote.
That's the problem with increasing fragmentation as an n+1 of the same thing and trying to do everything yourself rather than delegating and scaling effort and expertise via crowdsourcing and outsourcing through plugin maintainers.
An "opposite" of the Atom approach appears to be an extreme overreaction (rather than a sensible middle way) and fails to solve the problems it brought: a slow, wasteful platform and a tradition of abandoned, fragmented plugins (also a problem with Vim/neovim, emacs, VSCode, and JetBrains).
A balance would be a curated plugin marketplace requiring quality, continuing maintenance, and support. Atom, VSCode, and JetBrains have some curation, but not enough. I don't know how to solve this other than to charge end users subscription fees and pay people for their efforts.
Also, that brings up the problem of monetization. A number of plugin authors insist on trial, freemium, or paid-only plugins because it's not a spare time hobby for them. Lacking monetization, some plugins won't ever be created.
So I don't see how zed will solve any problem other that being art as wonderful technology applied to a tough, busy, competitive category without enough unique, competitive advantages to self-reinforce increased adoption. As such, it seems unlikely to ever morph into a complete and useful IDE to uniformly support every development niche. Even now, I have difficulty finding a usable Haskell IDE with commercial providers such as VSCode or JetBrains to wonder if zed will somehow manage to be better than any of them and/or vim.
TL;DR: I think Zed project leaders were overly ambitious, unrealistic, and failed to anticipate the endgame.
> Rather than selling you a proprietary editor, we'd much prefer to sell you services that seamlessly integrate with your editor to make you and your team more productive. Zed Channels is one example of such a service. It's free for anyone today, but we intend to begin charging for private use after a beta period of experimentation. Providing server-side compute to power AI features is another monetization scheme we're seeing getting traction.
But I'm with you. I can't see paying-for-shared-editing working. There are too many people using other random editors.
AI? Yeah maybe. I've paid for Copilot. But now they have to fund an AI research team as well.
I really really hope they succeed but I'd probably still bet against them.
It's fine. Every time Zed gets a mention on here someone finds it incredibly important to post the words "Mac only" without checking, even when, as with this thread, the topic has absolutely nothing to do with running Zed or what operating systems it can run on.
That’s just how things are on Windows. Building just about anything requires Visual Studio (not the UI but the tooling that comes with it. E.g. msbuild and C++ headers)
You won’t have to do this on Linux or if you use a pre-built exe
That's just the reality of developing for Windows. You don't need their compiler but you do need the headers. Same goes for macOS which requires installing XCode.
It's pretty frustrating to read so much about a thing, only to find out it's only supported on a niche platform that I don't have access to.
The fact that that isn't totally the case is a great thing to hear, and I would love to have learned this fact sooner. It would go a long way for Zed's team to at least mention it on the Downloads page.
Just every developer friend I know, uses Mac for coding. It is ubiquitous. In a BigTech company I once worked, there were virtually no guys having Win or Linux on their laptops, so we often even didn't test our internal tooling against those platforms, as almost no one used them...
Zed guys know their audience. It is developers, not gamers or office clerks.
Probably those are students + hobbyists + maybe Windows game developers? Or my anecdata is just not representative.
Maybe Zed considered it is worth targeting only Mac audience, as it gives much higher rate of people who would actually buy their editor (i.e. the rate of professional users, who code for living, is higher)? That is my guess, I don't have any data to back it up.
Sounds like selection bias at work. Developers are the most likely to choose both, a platform/OS to use for work, and a workplace where other people choose/encourage the same platform/OS.
If the people I was working with didn't bother to test their tooling on Linux, then I would be the one person on the team testing for (and porting to) Linux, and that would definitely motivate me to work elsewhere.
Web development doesn't bind you to a specific platform. And modern desktop apps are overwhelmingly Electron (i.e. based on a web stack). It is just simpler to develop than native, and gives you portability out of the box.
And if you're a mobile developer, you must have a Mac, because the proper tooling for iOS does not exist on other platforms. So even if you target multiple mobile platforms, you'd develop it on a Mac.
I think there is sort of a Pareto distribution, like 20% of apps generate 80% of the money or something like that.
Quick googling confirmed it: "Spending on iPhone users accounted for 68.13% of all consumer spending on mobile apps, while Android remained with a 31.87% share of app spending worldwide in 2024".
So while it is 30% in users count, it is 70% in spending. If you want your app to generate money, you'd have to make an iOS version, otherwise it would be irrational.
Same logic applies to desktop apps. It is irrational to spend resources on a native version if you can get to market faster and cheaper with a web-based thing. So from the first principles, today's successful and popular apps must be coded like that. Surely, there is still a lot of legacy...
Nice logic, except forgeting that there are countries where iOS hardly has a presence, and companies on those countries want to sell their stuff to people on that country, not foreigners on other countries.
Back in 2012 I threw together something like this for managing UI dialogs in C#. For all the hate async/await gets about being an over optimization, it's good to see people find use for it as an ergonomic tool outside of concurrency
Yeah it really needs notebooks and automatic venv discovery for me to use it for python. Having to define the venv in each projects config is just not needed in other pythons ides
Seems like a low cost to pay for that part being robustabd controlled by you. But this is from an emacs user perspective, perhaps ypu vscode guys have it better.
The biggest shortcoming of Zed is the lack of "remote development".
We almost exclusively write code in Codespaces-like setup, where you spin dev containers in the cloud, attaching to it from VSCode, so you don't have to run builds on your local laptop, and also heavy LSPs (like clangd) could run remotely on a fat RAM-heavy machine in K8S.
This is possible because VSCode had client-server architecture from the get-go, so it can run itself in an remote container, only having the GUI (light client part) running on your local machine.
There are LSPs that can be slower than the network, so having an extra hop doesn't impact the UX too much (in that case). I don't usually even notice.
Networks can vary also, depending on your/DC location, routes, VPNs, providers (and etc.), it can be under 50ms latency (which isn't even noticeable completions-wise) or over 1000ms.
The most important thing is that the typing itself is fast, as it happens on the local machine. Compared e.g. to vim running in an SSH session — that can feel really bad, especially if the remote machine is on the other side of the ocean. So compared to that, VSCode is a big upgrade.
If this is a significant share of market it should be fairly easy for Zed to go that direction, as the entire app is based around collaboration and pair programming.
Is VSCode involved in provisioning these dev servers, or do you just point it to an SSH endpoint?
> Is VSCode involved in provisioning these dev servers, or do you just point it to an SSH endpoint?
In our setup there is a web version of VSCode which you can run from a browser (that implies provisioning, yes), but I don't like it and prefer to connect to the remote box from my desktop VSCode, via SSH.
I love Zed and it’s been my daily driver for the last 2 months or so.
It was very fast until recently. I am guessing it’s the Rust stuff that caused the performance hit since I keep seeing a Rust-y error in the logs. Jumps, search and even saving files started lagging up to multiple seconds in some instances.
I think we also need an easy way to disable
/configure LSPs etc. I know it’s through the local JSON config but getting the keys and the values right and determining if it did what it’s supposed to do is a bit cumbersome.
93 comments
[ 3.7 ms ] story [ 152 ms ] threadhttps://zed.dev/blog/gpui-ownership
If they have the guts to try this full time I suppose there's really no excuse for me not having a go at my own thing.
It’s very clear the differentiation of Zed will come in the form of the collaboration functionality it will have.
I drove Zed for about a month, its very performant and a joy to use, but the lack of a remote development feature is massively prohibitive and I went back to VSCode as a result.
Let's see in couple years.
The biggest problem is to get those initial features decent so that you can extract the value from crowdsourcing the missing things like VSCode does.
Based on what I am seeing right now [1], they might well have enough inertia to seriously compete against VSCode. I've analyzed a lot of open source projects and their community engagement on GitHub is quite impressive. Their contributor and new contributor stats is still going up, even though the initial hype was 2 months ago, which is really impressive.
If they can get proper support for Linux and Windows and nail core features, I can see people wanting to contribute in the future and business leaders paying for it, if they can demonstrate improved productivity and collaboration.
Full disclosure: This is my tool
[1] https://devboard.gitsense.com/zed-industries?board=gitsense....
IMO this is the best feature of VSCode.
An "opposite" of the Atom approach appears to be an extreme overreaction (rather than a sensible middle way) and fails to solve the problems it brought: a slow, wasteful platform and a tradition of abandoned, fragmented plugins (also a problem with Vim/neovim, emacs, VSCode, and JetBrains).
A balance would be a curated plugin marketplace requiring quality, continuing maintenance, and support. Atom, VSCode, and JetBrains have some curation, but not enough. I don't know how to solve this other than to charge end users subscription fees and pay people for their efforts.
Also, that brings up the problem of monetization. A number of plugin authors insist on trial, freemium, or paid-only plugins because it's not a spare time hobby for them. Lacking monetization, some plugins won't ever be created.
So I don't see how zed will solve any problem other that being art as wonderful technology applied to a tough, busy, competitive category without enough unique, competitive advantages to self-reinforce increased adoption. As such, it seems unlikely to ever morph into a complete and useful IDE to uniformly support every development niche. Even now, I have difficulty finding a usable Haskell IDE with commercial providers such as VSCode or JetBrains to wonder if zed will somehow manage to be better than any of them and/or vim.
TL;DR: I think Zed project leaders were overly ambitious, unrealistic, and failed to anticipate the endgame.
> Rather than selling you a proprietary editor, we'd much prefer to sell you services that seamlessly integrate with your editor to make you and your team more productive. Zed Channels is one example of such a service. It's free for anyone today, but we intend to begin charging for private use after a beta period of experimentation. Providing server-side compute to power AI features is another monetization scheme we're seeing getting traction.
But I'm with you. I can't see paying-for-shared-editing working. There are too many people using other random editors.
AI? Yeah maybe. I've paid for Copilot. But now they have to fund an AI research team as well.
I really really hope they succeed but I'd probably still bet against them.
Interviewee: Vim
Interviewer: Sorry, we use Zed here
Either the candidate adapts and uses Zed in vim-mode, or the business allows the candidate to use vim. I certainly wouldn't make that a blocker.
https://github.com/zed-industries/zed/blob/main/docs/src/dev...
You won’t have to do this on Linux or if you use a pre-built exe
https://www.elmalabarista.com/blog/2020-install-rust-windows...
The fact that that isn't totally the case is a great thing to hear, and I would love to have learned this fact sooner. It would go a long way for Zed's team to at least mention it on the Downloads page.
> Download for macOS (Intel chip) Requires macOS 10.15+
> Download for macOS (Universal binary) Requires macOS 10.15+
there are no other buttons...
https://zed.dev/download
Lold hard on that.
Just every developer friend I know, uses Mac for coding. It is ubiquitous. In a BigTech company I once worked, there were virtually no guys having Win or Linux on their laptops, so we often even didn't test our internal tooling against those platforms, as almost no one used them...
Zed guys know their audience. It is developers, not gamers or office clerks.
Maybe Zed considered it is worth targeting only Mac audience, as it gives much higher rate of people who would actually buy their editor (i.e. the rate of professional users, who code for living, is higher)? That is my guess, I don't have any data to back it up.
If the people I was working with didn't bother to test their tooling on Linux, then I would be the one person on the team testing for (and porting to) Linux, and that would definitely motivate me to work elsewhere.
And if you're a mobile developer, you must have a Mac, because the proper tooling for iOS does not exist on other platforms. So even if you target multiple mobile platforms, you'd develop it on a Mac.
iOS is only relevant in 29% of the world, many countries don't even have a relevant iOS market at all, they are fully into Android and feature phones.
Quick googling confirmed it: "Spending on iPhone users accounted for 68.13% of all consumer spending on mobile apps, while Android remained with a 31.87% share of app spending worldwide in 2024".
So while it is 30% in users count, it is 70% in spending. If you want your app to generate money, you'd have to make an iOS version, otherwise it would be irrational.
Same logic applies to desktop apps. It is irrational to spend resources on a native version if you can get to market faster and cheaper with a web-based thing. So from the first principles, today's successful and popular apps must be coded like that. Surely, there is still a lot of legacy...
https://docs.rs/glib/latest/glib/struct.MainContext.html#imp...
This is an amazing idea.
We almost exclusively write code in Codespaces-like setup, where you spin dev containers in the cloud, attaching to it from VSCode, so you don't have to run builds on your local laptop, and also heavy LSPs (like clangd) could run remotely on a fat RAM-heavy machine in K8S.
This is possible because VSCode had client-server architecture from the get-go, so it can run itself in an remote container, only having the GUI (light client part) running on your local machine.
Networks can vary also, depending on your/DC location, routes, VPNs, providers (and etc.), it can be under 50ms latency (which isn't even noticeable completions-wise) or over 1000ms.
The most important thing is that the typing itself is fast, as it happens on the local machine. Compared e.g. to vim running in an SSH session — that can feel really bad, especially if the remote machine is on the other side of the ocean. So compared to that, VSCode is a big upgrade.
Is VSCode involved in provisioning these dev servers, or do you just point it to an SSH endpoint?
Maybe that part of the market is growing.
Being good at remote dev might sometimes be in conflict with super fast and responsive, or at least make it harder to be great at both.
In our setup there is a web version of VSCode which you can run from a browser (that implies provisioning, yes), but I don't like it and prefer to connect to the remote box from my desktop VSCode, via SSH.
Every time I launch VSCode or any other Web IDE, I have flashbacks of running X Windows over the network, or telnet into my Emacs session.
Nathan Sobo if your reading and interested hit me up: ivan at daytona.io
It was very fast until recently. I am guessing it’s the Rust stuff that caused the performance hit since I keep seeing a Rust-y error in the logs. Jumps, search and even saving files started lagging up to multiple seconds in some instances.
I think we also need an easy way to disable /configure LSPs etc. I know it’s through the local JSON config but getting the keys and the values right and determining if it did what it’s supposed to do is a bit cumbersome.
From Github's code stats, Zed is 97.3% Rust, so Rust is almost certainly both the problem and the solution here.