Zed Decoded: Async Rust
zed.dev
zed.dev
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
https://docs.rs/glib/latest/glib/struct.MainContext.html#imp...
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.
This is an amazing idea.
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...
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...
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...