Sequoia backs Zed
zed.dev
zed.dev
Having said that, I don't think an editor should be VC backed. It's the obvious pragmatic choice to get a team together to support a thing, but I'm concerned by it.
Here I am on my free-as-in-freedom operating system, making commits with my free DVCS tool in my free programmable text editor, building it with my free language toolchain, using my free terminal emulator/multiplexer with my free UNIX shell. VC backed tools like Warp and Zed that seek to innovate in this space are of zero interest to me as a developer.
Please please please, get paid rather than holding on too tightly to making things free forcing future enshittening.
You can pay for Zed today if you'd like - https://zed.dev/pricing - and also the editor itself is open-source under the GPLv3 license. So if at any point in the future Zed changes direction in a way you don't like, you are perpetually free to build the version you liked from source (or make a community fork and take it in a different direction).
I'd also much rather have a means of paying a single flat fee to indicate my support than yet another subscription which is misleading because I have zero interest in the AI components of Zed.
Since switching from Emacs last year, I have absolutely loved how this editor has evolved, and I am looking for any way to directly support the effort. I have been a Zed Pro subscriber for quite a while now, and I have started trying to contribute to the codebase, but I really wish there were monetization options beyond making a spread on Anthropic API pricing.
You don't have to give me any more features than what's in the free editor. I would gladly pay up to $300 just to have a "license".
So here's my ask: let me pay for it without paying for AI! None of my use cases will stress your servers; I have `"disable_ai": true` in my settings.json. Give me a $5/mo "support the devs tier" or a $10/mo tier with some random app quality-of-life features and I'm there. I specifically want to pay for good software without paying for AI to signify the value proposition that still exists there cause I don't think a VC would believe me otherwise.
Zed is fast, easy to configure (so far, maybe some hard parts I haven't run into yet), works well with the languages I care about via LSPs, and the collaboration features are compelling. I want to pay to support that, I don't want to pay for an LLM feature I don't care about that ends up distracting from the progress on the things I want to see maintained or improved.
If I'm wrong I'd love to know, but I think that we need to start talking about what funding really implies more honestly. It's traditionally met with unabashed enthusiasm and congratulations, which I totally understand, but it's a mutual exchange, not an award or a grant. I absolutely believe that everyone wants to make good on their promises, but promises made to users are not legally binding, and the track record for upholding those has not been great. Plus, as a user, I want to pay for software, but nothing feels worse than paying, then watching enshittification unfold anyways... When this happens, the investors should send you a nice postcard thanking you for paying back some of their money.
Can $20/mo sustain a text editor company with a massive multimillion dollar valuation? Well, we'll see. Good luck Zed Industries, we're all counting on you.
To clarify, I use AI agents, but I absolutely hate them submitting code in my editor. Chatting is fair enough and useful, but I need to turn off the auto-generating code part.
All they have to do is only permit official builds to talk to official builds (for security, of course ;-), and forking Zed becomes a lot harder.
Not sure how many people would use that though
Authoring plugins is a lot more attractive in lua, imho.
it's a software company. they sell software.
This is far fetched and that's why it cannot be taken seriously.
This is 100% pure virtue signaling. This brigading is not helping a single Palestinian. These people just want to feel and show the world that they are “the good guys”, while not actually doing anything or helping anyone. To me, that is absolutely a joke.
It's also faster than Zed, works on Linux/Win/MacOS, and is decently customizable.
Although at least to me, Sublime Text 4 feels like a "finished" product.
> Nor was I happy about the new 3-year-of-updates license model that ST4 adopted.
I'm curious what you don't like about this model? The most common complaint with regards to updates was the long waiting period between major versions, which we've now eliminated, and without changing the perpetual nature of our licenses.
I have had experience with quite a few projects switching to recurring billing, occasionally justifying it with "to support development of great new stuff" and then... just keeping the same rate of updates as before, resulting in a de facto steep upgrade. That said, three years of upgrades for 99$ is reasonable, even if there were only bugfixes
Thanks. I guess I'm just not really seeing how that is any different to what we did before? You'd buy a ST3 license with no knowledge of what improvements would be made to ST3.
Personally, I'm OK with using an old build so I don't mind that much about the limitation. Although if my 3 years elapses right before ST4 introduces first-class LSP support and an official Debugger, I may be very peeved. :)
That's correct, but it could be the day after you buy the license is when ST3 stops receiving any updates and we dedicate all work to ST4. With a ST4 license you're always getting 3 years of updates, ST3 it was anywhere from 3 to zero (not counting the beta period, ST3 only got 3 years of updates).
> Although if my 3 years elapses right before ST4 introduces first-class LSP support and an official Debugger, I may be very peeved. :)
I think we can all sympathize with some buyer's remorse. Unfortunately the line needs to be drawn somewhere. Maybe you can take solace in that we probably can't put multiple huge features in a single update, at least not a dev release. :)
You got everything in the current Major Release and every minor and patch update to it. If it took more than three years to release a new Major it was not a big problem, because you were still covered.
The new model might leave you without bugfixes before a new major version is out.
I lost track of what happened there (moved to Vim back then), was it VSCode that killed it?
I remember the extremes of the utter unconstrained chaos of Emacs and the rigid ultra-high-boilerplate approach of the Eclipse IDE. Emacs was fun to hack on, but impractical to use as an IDE, because if you installed enough plugins to make it useful as an IDE, it was broken half the time (my experience, many years ago.) Eclipse had a robust architecture, but writing plugins for it was a dispiriting slog, even when I got paid for it (again, my experience, many years ago.)
Unironically, maybe VS Code.
Everything simple you can do with it, either comes built-in, or within Github/Microsoft ecosystem, or has an official plugin that gets recommended and featured by the editor itself. Plugins from individual hobbyist developers I have, I can almost count in one hand. (VSCodeVim being the most important one)
Now I compare this to my Neovim setup, and that one is basically running on charity from OSS developers.
I have completely opposite experience with [modern] Emacs. Of course, it wasn't smooth from the day one, but neither was my ride with different IDEs. Somehow, I keep coming back to Emacs because no IDE ever provided all the machinery I need to be productive. For me (and I suppose for many other people), Emacs is far more sweeter spot of an IDE than any other alternative.
For what it's worth, I went from ST3 -> VSCode -> ST4, and have been happy since. I've found that I prefer my text editor with minimal extensions, and with Sublime Text's LSP Plugin, I'm pretty content. The performance and customizable UI make it more worth it to me than VSCode.
Well, OK then. Back to Emacs I went.
With that being said, just a quick look at, for example Stack Overflow 2025 survey tells me it doesn't have the same mindshare it once had.
There needs to be a critical mass of people using it for things that aren't core to stay updated
The key plugins I use are some LSP servers, and they work wonders. The few languages I mainly use (yaml, json, TS/JS, python and Go) I get great language support for via the LSP servers and the editor is blissfully fast always.
I could live without even the LSP stuff, but the one feature I can't live without is Sublime's excellent recovery support. Every once in a while my system will crash, and even though I've had multiple unsaved buffers Sublime recovers them every single time. Saved my butt more times than I want to know!
As for people in general, safe bet in almost any topic is that most people won’t care. :) So yes most people use VSCode.
I still use it, it is maintained and it is very good and fast, and that it didn't try to reinvent itself is a good thing for me. But it is not a full IDE (not Jetbrains), it didn't jump on the AI bandwagon (not Cursor), and it is not free (not VSCode), so it is not surprising that it lost some market share. But it is not dead.
In reality 70% of the people I see are using Cursor (Subscription), Vscode (Free) or some JetBrains products (Subscription). I only know of some people including myself that have ST for opening large files, where performance matters.
I'm a fan of indie software and native apps but I know zero people in the past 10 years that switched to ST. I know plenty of people of people who switched to Vscode and all the other free or paid competitors. It's probably enough to sustain a small company, and not everyone has to strive for a monopoly. But I wouldn't call that thriving.
People are 7x more likely to be using VS Code, which means that a niche tool is far more likely to have a VA Code plugin than an ST plugin.
Other than that, if the 11% of people using it are happy then there’s no issue.
They switched to a subscription model (3 year licenses are still subscriptions), and since the release of ST4 in 2021, there has been exactly one release with new features (May 2025). All other releases have been bug fixes and "improvements".
I get that developers need to make a living, but 4 years of fixing bugs in your products is probably not what I want to be paying for, at least not when that is the only thing I'm getting. Speaking of releases, they're also usually 6-12 months apart.
I have used ST ever since the first version replaced TextMate for my use (TM2 spent something like a decade catching up to ST2), but I've since switched to Code and Zed (mostly Zed as of late, Code on windows until Zed is ready there).
ST was great back when it was still an actively maintained product, but in recent years (ever since ST2) it has felt like it was mostly on the back burner and other editors have passed it in functionality.
As for VC funding, it has done miracles for Code to have Microsoft sponsor it (and others). Code is currently the editor to beat for anything that doesn't involve opening large files.
vscode seems to have totally taken over dev mindshare these days.
vim has a universal and in many ways a eternal use case. You have to edit a file at some point on a server, be it a self hosted or even on ec2. Thats kind of the only real use case for vim.
In these days of AI assisted coding, no one really 'edits' code. A lot of editor short cuts and fluency related concepts kind of in many ways are not relevant in this paradigm.
The thing is vscode just works, like just works, for nearly all the usecases. In case of emacs, learning it and mastering it takes lots of time in ones career. In case of vscode you don't have to do this, you can straight away work on the project that you want to get done.
emacs is some what like a massive distraction from the actual task you want to achieve. Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code. In vscode you just write project code.
Emacs and Vim has this built-in. Other editors kinda have that, but it's clunky. I can suffer IDE because they provide a lot more than editing.
> Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code
That's only done once. It's like adjusting the mirrors and seats of a car. Once it's comfortable, you don't have to touch it. Using VS Code feels like borrowing a car with a very limited range of adjustments. Why is the explorer on the left and the terminal at the bottom? Why are they always there?
The "distraction" framing assumes everyone has the same preferences and working style, I for one find VSCode (and IDEs in general) massively distracting from productively solving many tasks. No, it's not "a skill" issue - I have used InteliJ every single day for almost a decade, diving into some profoundly advanced and non-documented features, and I do open VSCode from time to time.
I feel your argument conflates initial learning curve with ongoing productivity, and assumes VSCode's approach is universally optimal rather than just different.
I am one of those experienced Emacs users myself. Wrote more stuff in Emacs and even vim than most devs today will even write code over their careers.
Its just vscode now does simply too many things out of the box, you obviously can recreate that in Emacs, but its a pointless exercise. Time consuming, and distracts your from your real job. My job is to write code, not build emacs to write code.
I totally stopped using Org-mode, because Google docs do it way better.
At some point you have to move on. For some people like that point arrived a little early.
Can you name Emacs packages you've authored, maintained or contributed to?
> vscode now does simply too many things out of the box
Oh yeah? Can you edit your filesystem in VSCode like a wiki? Changing directories and filenames as if you're editing plain text? Can any of thousand of its extensions provide "indirect buffer" experience? Can you bind a double tap of the comma to navigate to the last error and automatically fix it? Can you at all bind to double/tripple comma or just about any arbitrary key based on context in VSCode? Keyboard macros with counters - e.g. to transform lists into numbered lists? True buffer based (not file oriented) workflows? Occur-mode style search and replace? Comint style process interaction? Are there any extensions that allow you to move the cursor to the piece of a plain text like "rfc-3540" or "myproj#4044", intelligently recognize it and allow you to browse the RFC document or review a Pull-Request - Emacs does. Can you run a shell command and pipe it into a buffer, or pipe the content of a buffer through series of shell commands and into another buffer?
> I totally stopped using Org-mode, because Google docs do it way better.
Don't be ridiculous. They are completely different classes of products. If you are even having to compare Org-mode with GDocs, perhaps you don't know well either or both. GDocs can't manage my dotfiles. I can't use it to annotate books or academic papers. I can't have inline LaTeX formulas in GDocs. It can't let me control a videoplayer and type my notes at the same time. I can't use it to manage my flashcards or keep the log of my LLM interactions there. I can't have executable blocks of code - in org-mode I can explore APIs or send SQL queries while passing them into data transforming code blocks. There are no TODO states/keywords in GDocs, no agenda views, no scheduling/deadlines, no time tracking/clocking, no habit tracking, no pomodoro timers, no dynamic time tables, no tag-based filtering, no capture/refile system.
> At some point you have to move on
Like I told you already, you're assuming too broadly. Both VSCode and Google Docs are excellent products - no denying that, but they are not universally better. If you came to the opposite conclusion, it is yours, and yours only.
Licenses are perpetual. It is not a subscription. Don't like the work we've done? You can continue to use that version of Sublime Text until the end of time.
> there has been exactly one release with new features (May 2025)
August 2024 we added kinetic scroll and xdg-activation support for Wayland; we also added the ability to configure image extensions and allow dynamically switching between the hex-editor and image view.
November 2023 we added native font dialog support for switching fonts.
August 2023 we added webp and proper support for running as administrator on all platforms.
November 2022 we added syntax-based code folding and operating system recent file integration
December 2021 we added GB18030 support.
I'll stop there. Those are just the largest, most user facing new features, not any of the new settings, new APIs or improvements that I'd argue are new features.
You can read the full changelogs here: https://www.sublimetext.com/download
> Speaking of releases, they're also usually 6-12 months apart.
We do stable releases infrequently, because they're stable. If you want more frequent releases you can switch to the development releases. You can see from the build number how many builds we've done of ST4 since the release: it's around 150.
Or until some change in the underlying OS makes it no longer able to run. Not saying that happens frequently, but it does happen.
> I'll stop there. Those are just the largest, most user facing new features, not any of the new settings, new APIs or improvements that I'd argue are new features.
New font pickers, settings dialogues and other "polish" is hardly what i'd call new features. I listed those as "improvements".
I'm not trying to start a fight, and i respect the work that has been done, but VS Code releases more features in a month that ST has released in the entire ST4 lifecycle, as does Zed. I understand the team is (a lot) smaller. My frustration is that when a new release comes out, it's mostly polish, and not fixing the real problems, such as lack of integration and plugins.
You may choose to brush it off as just an old fart rambling on the internet, but i'm not alone with this opinion, and i have ST licenses dating back to the original version, and i have chosen not to renew my ST4 license. When you start losing the "religious" users, maybe it's time to reevaluate ?
1. Everyone else is building on Electron.
2. People still sleep on or dunk on Rust. There's a great deal of negativity here on HN for the language.
3. There's only so much Rust talent out there.
Stating that everyone else is building on Electron belies your lack of exposure to any editors other than vscode \ atom spin offs.
Realistically all the editors including those based on Electron could easily shift to leveraging the GPU more and that would be big leap forward for performance.
Enlighten me.
It's not hard to look, I would wager a small percentage of these editors are Electron based.
Also, it doesn't have to be rust, it could be C# or Zig or Lua or whatever
- You can make money when your product is a text editor.
I am very skeptical of these claims:
- When your product is a text editor, $42 million in capital can be effectively deployed to make meaningful improvements to your product.
- When your product is a text editor, your lifetime inflation-adjusted profit will eventually exceed $42 million.
Sequoia is apparently not so skeptical, and willing to put the money on the table. That must have been a truly extraordinary pitch deck...
Unsure of what the end goal is, but I expect everything AI related to be a load-leader right now and then the goal being to figure out how to drive down costs or make even more money later.
Maybe that's what Sequioa thinks too...
Neither Google nor Claude nor anyone can’t at the moment get right basic operations like file edits. Zed is flawless in co-operating with most LLM models. And not just that - also switching models during conversation and more.
I am at Zed Pro at $20 but when Zed offers $200 Max plan I will sign up right away.
Even with "auto edit" turned on, Zed just kept asking me for confirmation. I'd be like "hey your code has this bug", and it'd be like "you're right, and this is why. here's how you can fix it" ??? just fix it man it's your code. Maybe this is fixed now, but Claude Code never has this issue and is very good at only stopping when truly stuck (and generally for good reason!)
Changing the topic a bit, Zed's collaboration features seem really good but it's quite hard to use when nobody uses it in the first place. With VSCode, I can use the LiveShare extension and everyone on the team can just join with no fuss at all. LiveShare is likely not nearly as technically great, but the simple fact that people can use it easily makes it win hard.
Honestly it would be cool if Zed can somehow become more popular thanks to this investment. As long as it can keep its speed and technical excellence. VSCode used to be super lean and cool, but now it's just another fat IDE with unlimited bells and whistles. It feels like how Eclipse felt back in the day.
They invested like $200 million in FTX and had a glowing article about SBF about mile long on their website.
The big VC firms are by no means immune from just doing plainly stupid things.
Right now all the hype around anything even at the periphery of "AI" is enabling a lot of similar stupidity.
Obviously, the risk here is very high from this perspective, since nothing guarantees anything.
They are giving out the actual text editor for free.
I understand people's concerns about VC funding, but I think building quality products takes capital. The funding is still relatively small, especially when you compare it to players like Cursor, etc. And I think Zed is a much, much better product!
Zed being OSS is a gift to the community, and I suspect DeltaDB will be as well. And as others have said, Nathan (CEO) is a delightful human.
Congrats, Zed!
Hate cancel culture as much as the next techbro, but since y'all point out they're "a delightful human", it'd be interesting to see how Nathan then responds to concerns raised in some quarters: https://github.com/zed-industries/zed/discussions/36604
When VC funding comes in it stops being about building any products, because the company itself becomes a product.
If they stick to their current path—focusing on craftsmanship and letting their world-class talent build the best editor—they risk falling behind giants like Cursor. Cursor seemingly came out of nowhere and is already doing $300–400M annually, rivaling JetBrains (who took 20 years to get there) in just two years. With that kind of momentum, Cursor can now buy their way into a superior product.
On the other hand, if Zed takes more VC money, it likely means doubling down on AI in ways they clearly don’t seem eager to—but at least it would give them a fighting chance.
I really feel for this team. It couldn’t have been an easy decision, and from the few interactions I’ve had, they strike me as incredibly talented, kind, and genuine folks. I truly wish them the best.
And on top of that, since it’s essentially just vscode, it costs users almost zero effort to make the switch. It’s the perfect crime!!
I hope zed does well though. I love their blog, and all of the cool open source stuff they’ve made. I recently heard they added a “helix mode” which might be enough to get me to switch from vscode…
zed came at the incredibly (un?)fortunate timing where they were just able to build a solid base before the editor wars began. their only path now is to fully maximize the few advantages they do have:
* a fresh base that is far more flexible
* really good experience with performance, design, general craftmanship
* a buzzy community and fresh/boldness that attracts vcs
for zed to truly win (at least in sequioa's eyes) they will need to completely take over vscode as the new default, and that will require a big lead when it comes to collaboration and ai
Revenue, not profit. I’d imagine cursor loses a dollar for every 50 cents of revenue and makes it up in volume. Meanwhile JetBrains is a profitable company not beholden to the whims of outside investors.
I know which I’d rather work for…
Zedless: Zed fork focused on privacy and being local-first - https://news.ycombinator.com/item?id=44964916
Zed for Windows: What's Taking So Long? - https://news.ycombinator.com/item?id=44964366
Developers don't think in terms of commits; they think in terms of Tickets and PRs. Git doesn't have any native representation of either of these things. Getting tickets into the repository is something the community has talked about for years, and Linus himself has said he wants, but it hasn't happened yet. Branches work fine enough to start a PR, but then Github, again, has to take over for comments, CI execution, even the decision on how you want the commits on that branch represented on the main branch (squash? merge? rebase? why should I care?). LFS has been years in the making. Monorepos are still weird.
Idk, I think there's capacity in the industry to take the concept of a repository back to square one and think more holistically about how we all interface with the repository. The way they talk about DeltaDB gives me hope that they'll start thinking more about this with this funding; commits just aren't a useful primitive anymore, and a repository, locally-downloaded, open source, ultratight connection between diffs, merges, communication, and automated tooling is how I want to be coding in 2030.
I wonder though what the play is here for Sequoia - like all VCs they’re looking for the possibility of a huge return.
I don’t see how “just” an editor (even with paying users) can generate a 10x return. So what is the larger vision here?
This means the company is funded, development will continue, zed will continue to improve. An IntelliJ style license (for example) is an acceptable trade-off from my point-of-view
So at some point Zed will likely need to pursue monetization more aggressively than IntelliJ does now.
You take the funding so that you can outgrow the competitors and get the market faster. All you need is the small promise of innovation in an area which is somewhat new. At the beginning, the product is good enough and you have money to keep marketing and developing slightly faster than others. This will get you the users.
In the end, is your product at that point truly the best among competitors? It matters less, since you already have the users.
I think Zed didn’t need this one since they had a great product. Many would have been ready to pay at least a little. They could have grown slowly and see what works. With VC money take can go to completely wrong direction with giant steps and they are not noticing that unless it is too late. And then investors want returns.
It’s refreshing to see an editor that’s built with performance as a priority.
I was a customer for so many years. "One IDE to rule them all" and then they started cashing on more.
Progress was down to a crawl, performance down the shitter and bug reports go unnoticed for 2+ years.
VSCode poops on IntelliJ these days for everything but the UX; but with enough modding, it can be very close.
What are you talking about?
ReSharper came out 21 years ago 3 years after Intellij. RubyMine came out 15 years ago. 7 years before CLion.
Like I said it's only one of the problems, read the rest.
I'm sure the free version has lost some things.
Its been a long time since I used CLion but it was the best C++ IDE by a huge margin.
Only ones that it can't is C/C++ (probably because that started as Apple only IDE) and .NET (that started as extension for Visual Studio).
They started Fleet that can do all of them, as a response for VS Code. But then came AI and Cursor probably took a large chunk of their users. So they redirected resources (like Zed that paused their collaborative features to focus on AI). There is currently a closed EAP for Cursor like ide based on Fleet. And their Git client as separate app.
The days of using a separate IDE for each language are kind of over.
These very paradigms are outdated these days. vscode got it, very early. vscode works for everything. Most projects use Python/Go and JS, and out of the box vscode just works for all these languages and their tools.
IntelliJ did that before Atom even had ‘git init’ run on it.
Seems to solve a real problem which is growing rapidly, both in the old way and in the new way ... if it can overcome _slop_ in LLM chats, and the sheer enormity of code/data ahead. Trying to picture how coherence will survive.
With claims/hype/concern floating around that >90% of code will be LLM-generated within 3-6 months, with the insinuation/tone [1] that the same amount of code will be written by humans as now ( at least at first ) but LLM code will radically grow to dilute the space ( as is happening ) ... seems like DeltaDB being done right/well is going to be do-or-die on whether coherence remains possible!
[1] https://www.businessinsider.com/anthropic-ceo-ai-90-percent-...
>I think we will be there in three to six months, where AI is writing 90% of the code.
They're going to keep saying it because it's a juicy sound bite and they're sales people. That doesn't make it any more true than "9 out of 10 dentists recommend our socks" or how we surely have all had flying cars for decades now.
The thing wrote at least 80%, so we aren't far off in this anecdotal instance. There are citizen devs who are building fun things for themselves where the AI does 100%
It made me realize these things are more capable than I knew, though they still do dumb stuff reliably. But, it is easy to undo those changes, so the productivity boost remains
Despite the article being salesmanship hype ( at WEF no less ) we are now in the time mentioned, and can feel this
The idea that the code is GOOD or even being used is not necessary to be saying that it exists, strewn everywhere
VCs operate from the goal of xtreme high user market share as the problem..
As frameworks get better, the audience using the IDE changes...
Both are misaligned before even meeting and it will get worse once VC money control is added.
My bias, I am a flutter framework user and MS VSCode user.
this feels pretty important; git is definitely not the right primitive for version control with ai and that pain is obvious with existing solutions. zed seems to be going all in on collaboration with realtime, git, and now something in between and it'll be interesting to see where they end up-to me three solutions feels overcomplicated but that may be necessary given how teams work now.
- [1]: https://zed.dev/blog/crdts
The Zed developers quickly refocused on milking the AI cow.
I'll argue git is plenty good, and there are a lot of people who don't understand it very well. The ones talking about Github PRs as if they were related to Git in any way most definitely don't.
I have a light fork that tries to nullify this, but I don't think I've managed to catch all the instances.
Other than that, it's a very nice editor in my opinion.
{ "server_url": "", }
I comment out that JSONC line periodically when I feel like cherry-picking updates
I hate this pattern in software so much.
Any data to backup this?
As mentioned in other comments, it actually outperforms window management in general in many/most cases. Radically flexible and almost never gets in the way
The modern Sublime Text is Sublime Text. There is way too much "extra" in Zed to compare it. If anything, it's a new IntelliJ.
Perhaps the same issue that had Zed fail to recognize their GPU also tanked their performance.
I do not understand how one says this with a straight face unless you’ve never used either product. Do you also believe Neovim to be a “new IntelliJ”? That’s the level of functionality out the box, though fortunately Zed does not require lots of screwing with config files to get basic things working.
It's funny how often people buy into the marketing and say "blazing fast" without actually questioning it. FWIW, I still prefer Zed because its LSP integration and vim mode are better than Sublime's.
Like any company now is "global leader in X market".
I know it probably didn't, but I wonder if part of Sequoia's decision to invest had anything to do with these false claims?
RIP Zed, you had a good run.
Let me guess: DeltaDB is free to use as long as we host your data and have free range on training AI based on your editor interactions.
My read was that they are pulling a Linus Torvalds with the Linux->Git move where both are innovations on their own, but work great together ( without dystopian universe instantiation )
CRDTs mentioned: https://zed.dev/blog/crdts
that said atuin is excellent
You know where this goes.
Also how on earth do you handle conflicts?
This sounds most similar to IntelliJ's local history tracking, but that is local only which makes sense.
Still, more IDEs is always good so I wish them luck and will wait and see. (As with Zed - I keep trying it but it's still very alpha quality so I always end up back in VSCode.)
I don't want chat with coworkers in my IDE, nor do I feel the pains they describe with conversations spread between tools. It's not a top 5 problem
What I also have not used is vim emulation, though I have a vim background
As mentioned elsewhere, Zed is still very configuration-dependent to get the full power of it, and a lot of its functionality is never discovered for that reason
What pushed me to try it was Ollama integration which is not an afterthought, then I realized I loved it _way_ more than SublimeText, especially on performance, at first, then everything else once that won me over
I have ~10 running instances at any given moment, and >99% of the time never feel any lag, whatsoever
Another unexpected benefit is that terminals, code editor panels, and assistant chats, get to be sized and fit wherever you want, so it is also kind of a window manager... I often have more terminals open in Zed than in the Window Manager of the OS itself
I give lots of feedback to Copilot in the hopes it makes the agents better in the long-run. I want them to read my code and train on it, along with the interactions with copilot, which is the next frontier in (post) training
I currently have 19 instances of Sublime Text open, each to a separate folder containing a mix of C++ and Python code bases (some tiny some huge). Like ~8 of those have the clangd LSP plugin enabled. I don't think I've ever experienced lag in Sublime. KDE System Monitor is reporting 2.0 GiB of ram being using by sublime currently.
The clangd LSP plugin in Sublime isn't perfect, and it does occasionally break, and rarely spikes in CPU usage for no reason (although the editor always remains responsive). But, if I ever switch away from Sublime Text, I cannot imagine it ever being due to performance reasons.
The issue is again people, they don't wanna change their _archaic_ workflow, stuck with inefficient -copy/paste- loop to the chat (ie. Slack) and back.
The story in the article went a bit too far that I agree, but I guess that is their north-star vision. Current implementation allows you to "join" a workspace session shared by someone, edit the same or different file, follow/watch a certain person, as well as have a chat (without requiring copy-paste) about certain piece of code. (both written or via voice)
If something, large enterprises generally don't support smaller and ambiguous licenses. Therefore, if Zed will allow enterprise licensing (ie. via on-prem license server or volume ordering, SSO, whatever) that would increase their adoption quite well...
I'd be interested to know how much data DeltaDB accumulates over time - because the level of granularity is so high - and are they going to want to use that data as training data?
Well done I suppose to the Zed founders as they're on the Sequoia gravy train now. But as others have noted this puts an inevitable clock on the enshittification no matter how hard the team crosses their heart and truly believes otherwise (or not, I mean maybe this IS the gameplan).
Hopefully Zedless [0] gets some community steam behind it.
It is a godsend on quickly debugging the why of things. If anyone knows how to replicate the same functionality with the same number of clicks in zed, id happily switch back to it.
there is also inline-blame, both are native (ie. no plugins required)
It seems such a silly thing but it made me not use zed at least until vscode eats all my ram again.
// ${XDG_CONFIG_HOME}/zed/tasks.json
[
{
"command": "git --paginate log --follow -p -m -1 ${ZED_FILE}",
"label": "last-file-diff:${ZED_FILE}",
"shell": { "program": "sh" }
}
]
// ${XDG_CONFIG_HOME}/zed/keymap.json
[
{
"context": "Editor && mode == full",
"bindings": {
"ctrl-shift-g d": [
"task::Spawn",
{ "task_name": "last-file-diff:${ZED_FILE}" }
]
}
}
]
The product has improved so much in the last year, it's been a pleasure to use and get excited about new features.
1) Their LLM integration needs to be at the quality of Cursor and VSCode to pull people away from those
2) Reduced friction to move over (keyboard shortcuts, common plugins, etc)
I think the Zed team is perfectly capable of winning. The bigger risk would be them trying to tackle fancy stuff before making sure the basics are good enough to get developers to switch.
They need to build up a deep understanding of why folks are sticking to Cursor/VSCode and not swapping over.
P.S. I would love for Zed to win in the market because I'm sick of slow software and it's refreshing to finally see an intense focus on performance.
That and the ever-trailing "especially now with AI".
As a user, most IDEs/Editors currently show in _eager_ way. For example, VSCode by default shows ghost-text as well as Amazon Q extension too. Usually disabling those disables the AI completion completely.
Meanwhile I like Zed's approach that you can trigger completions with Alt+Space, not burning through your "tokens" in free-tiers. They also provide a free-tier completions, as well as _next-edit suggestions_.
*) Next-edit suggestions: When you edit some piece of code repeatedly, it suggest to do similar on the next few instances, with context awareness, quite nice feature saving several keystrokes every single time.
For example, I don't like that I am forced to look at its "Sign In" UI, and that they have refused attempts to remove it. [0]
Zed has some much more annoying bugs, and I am not excited to help fix them given the position of the code owners.
I am certain the team will say that is not on the roadmap, but for me, it still sounds like a possible leak in the future.
Or maybe a semi draconian "mandatory" extension your bosses will demand installed.
Zed has better drawing speed. But DeltaDB bloat, AI bloat, telemetry, need of modern videocard.
Hopefullly intended use is to schedule a time for it.
One of the reasons I find LLMs don't increase productivity much is that I can't switch branches to multitask while it's processing. Context switching isn't always useful but there's still lots of opportunities for rapidly experimenting or ticking off a couple small bugs quickly while AI takes the first pass on something more complicated.
Each "branch tab" could have a sort of TODO list or plan.
Git worktrees are great for this. I built a little tool to make them more ergonomic: https://steveasleep.com/autowt/
You really don't need every LLM vendor to build their own version of worktrees.
It just means that we will now see AI crapola being stuffed into this editor in the next few days.
"total funding to over $42M"
the enshittification it'll take to extract $400m of value out of a text editor will be dismal
"Fast" is what got me interested. All this other stuff sounds like "we want more money"
Still missing some key features to get parity for python with PyCharm, and git features need more love, but pace of development has been blistering. Kudos to the team for building something really solid.
I don't use the agentic stuff though -- I have a ClaudeMax subscription and use CC or more recently opencode (the only non-CC that works with a ClaudeMax sub); I don't want to pay another sub for Zed and the free model use that comes with Zed runs out very quickly (understandably so, no complaints there). If I could connect my ClaudeMax sub to it then I'd maybe use it, though CC and opencode are pretty good.
The code completion is decent and I especially like the "subtle" mode saves a lot of backspacing (no, dammit, that's not what I wanted!).
I understand Zed needs to make money, but VC backed, especially Sequoia, doesn't inspire any love, tbh. I don't care what platitudes VCs say about independence their love for the product etc., they need their 10x return and if it means enshittification, so be it, they don't really care.
I think thinking in solitude is still better than that
Getting developers to switch is going to be hard.
Personally I don't think they can do it.
I am a 10 out of 10
YES!!!
I miss some of his old posts that he took down from his website, in particular the one on learning statistics, that was a great one.
He seems to be saying he spent $350k making this. I guess it's some tooling for writing parsers.
He has this to say about Zed:
> Zed: Founded by Atom’s dev team, Zed was the rewrite that Atom always wanted to be able to do but couldn’t when Microsoft bought Github and made the executive decision to kill a product it might otherwise have had to compete with. Unfortunately Zed decided to do that rewrite in Rust. This has slowed their iteration speed, caused much of their dev effort to go to cross-platform support instead of innovation, cut them off from being able to offer their experience on the web, severely limited their hackability, and generally made theirs a niche tool for enthusiasts. What’s worse, their reliance on LSP — a product which believes that the presentation layer should be the primary abstraction layer — means their product is forever doomed to look like a VSCode knock-off. [1]
We're approaching the problem by drawing from browser design. We want to see an editor with a DOM API for code documents. BABLR is a parser framework meant as a direct answer to Tree-sitter.
A standardized DOM for code would provide a universal way of changing code documents using scripts and would allow many different code-oriented tools to interoperate naturally where they never could before.
It's not clear to me how you could substantially replace the capabilities/benefits of what LSP provides with BABLR either.
- Our core and grammars are relatively tiny and can easily be loaded into any web page as a syntax highlighter, except actually a bit more: more like being able to embed ASTExplorer directly into your docs page or blog post to help people understand code examples.
- We support runtime extensibility of languages, e.g. TS can extend from JS at runtime. Tree-sitter only supports static linking, so every shipped language extended from their JS grammar contains a complete copy of the JS grammar.
- Our grammars are much easier to debug. They're written as plain scripts, and they can be run and debugged in exactly the form they're written in.
- We can parse inputs with embedding gaps. An example of such an input would be the content of a template tag before interpolations have been applied. Parsing after interpolation opens the door to injection attacks, but parsing before interpolation allow safe composition of code fragments using template tags.
- We emit streaming parse results on the fly, and can parse infinitely long data streams with ease or syntax highlight. within large single-line files without freezing up
- Tree-sitter is half an IDE's state solution: "just add text buffer". Our solution is the whole thing. One stop shop. IDE in a box.
- CSTML lets us do round trip serialization of any tree and also gives our trees stable hashes. Tree-sitter could trivially represent its parse results as CSTML if it cared to, giving it competitive compatibility with BABLR. A rising tide lifts all boats.
- While they're setting out to make version control for the first time now, we're already basically as powerful as git thanks to the combination of hashed trees, immutable data, and btree amortization within nodes for maximum structural reuse of data.
- Did I mention you don't have to deal with this? https://github.com/tree-sitter/tree-sitter-typescript/blob/m...
- We can probably literally just run the Javascript source code for Tree-sitter grammars on our runtime. The only problem is the C lexers, but C lexers are one of the great annoyances of tree-sitter anyway since any context in the grammar requires you to hand-write the lexer