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.
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.
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.
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.
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.
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.
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.
