Zed is exactly how software should be made. Granted, I don't agree with all of their UX decisions (i think the AI panel is really bad compared to Cursor's), but good lord is the thing fast. These guys are the real deal. They built a rendering system (GPUI) in Rust before building Zed on top of it, and so it is one of the fastest (if not the fastest) pieces of software that resides on my computer. I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it, because the other Rust GUI libraries/frameworks aren't great.
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
Man, so true. I tried this out a while back and it was pretty miserable to find docs, apis, etc.
IIRC they even practice a lot of bulk reexports and glob imports and so it was super difficult to find where the hell things come from, and thus find docs/source to understand how to use something or achieve something.
Super frustrating because the UI of Zed was so damn good. I wanted to replicate hah.
part of me wants to dedicate time to making something with it and then creating examples/PRs -- but it's too unstable given how fast they're moving for now IMO. if anyone from Zed team can chime in and confirm, that'd be awesome.
i have and it's more of the same (unless i'm missing something). the fact that the entire thing is editable is weird to me. i really think they should just clone cursor's in this one case because they really nailed the UX with the checkpoint restoration
edit: yes i missed something. i see the new feature. hell yeah!
Its the opposite to me. I really liked that the AI panel was a fully featured text editor buffer like any other. The new agent panel makes it too much like "the rest" haha. I guess I'll get used to it over time. The important thing is that we finally have agentic editing which is extremely powerful ofc.
Ah, that's still the old one - the whole thing is no longer editable in the new one we launched today. (You can still access the old one, but the new one is the default as of today.)
Check out the video in the blog post to see the new one in action!
I really miss the everything is editable panel, it felt like a superpower. There’s a bit of a learning curve, but after it’s amazing and everything else feels limited.
I’ve been using Zed a few months on my fedora laptop (thinkpad x230) and haven’t had any performance issues. Definitely faster than any other graphical editor I’ve used. Perhaps a driver issue would be slowing it down?
You should report an issue with your specs, not just say “other applications don’t have this problem” — especially as a Linux user.
For one, not all applications are GPU accelerated.
Two, their UX may need to be improved for a specific hardware configuration. I have used Zed with good performance on Intel dGPU, AMD dGPU, and Intel iGPU without issue — my guess is a missing dependency?
Meh, it's not worth the trouble. I don't care enough about using Zed to fix their Linux distribution problems or debug something for them. This isn't some volunteer backed FOSS project where they get a free pass or free QA work from me.
What's the point of commenting that it's slow if you don't care about using the program and switched to something else? Also, how is whether the project is volunteer-run relevant? Would you file a support ticket for commercial software you use saying "it's slow" and then when they follow up asking for details about your setup, you say "sorry, you don't get free QA work from me"? Do you really think that would lead to them fixing your performance problem?
The point was contradicting another comment with my own experience, not to putz around with bug reports or trouble shooting.
I don't care about Zed fixing anything - they're Zed's issues, not mine. All I'm saying is that contrary to what someone else said about the software being "fast" I tried it and at startup, it was unusably slow. I'm what you would call a failed conversion.
> Also, how is whether the project is volunteer-run relevant? Would you file a support ticket for commercial software you use saying "it's slow" and then when they follow up asking for details about your setup, you say "sorry, you don't get free QA work from me"
So this is kind of needlessly antagonistic imo - the point between the lines is that FOSS projects run by volunteers get a lot more grace than venture backed companies that go on promotion blitzes talking about their performance.
But you run Linux, with its myriad of software configurations. And if this thread is correct Linux support is already far along, if it runs well on something old like the X230. It is not a realistic expectation for any project to work on your hardware if you are not at least willing to report an issue, or rather: No software will run flawlessly on all hardware always, that's not realistic.
Error message, hardware configuration, done.
From my perspective that is not something you do for zed, but something you do for your distro and hardware.
And ofc, your first comment was fine either way. But the attitude of the latter is just poor.
Once you get a knack for it, you can see that the original comment of "So I guess it's only fast on macos?" already has an attitude, and the rest of the thread comes at no surprise.
How about "I'm getting <1FPS perf on {specs}" instead of the snark.
This. Honestly, their issue based on Zed’s issue tracker is likely with NVIDIA drivers inconsistencies, which ironically is due to the closed source nature of NVIDIA drivers (its workarounds all the way down bringing pain to app and driver developers), not Zed (which is indeed FOSS, just not “volunteer” driven).
You’re both being antagonistic. While Zed may be VC backed, they’re providing a world class open source editor experience for free. There are no expectations in either direction. You’re not a special customer paying them to care about Linux. And you also don’t owe them volunteer effort to help resolve some Linux issue you encountered. They failed to convert. You missed out on honestly possibly the best editor out there right now. That’s that.
The antagonistic part is assuming your specific Linux configuration is innately Zed’s issue. It’s possible simply mentioning it to them would lead you quickly and easily to a solution, no free labor needed. It’s possible Zed is prepared to spend their vast VC resources on fixing your setup, even—which seems to be what you expect. Point being there’s a middle ground where you telling Zed “hey it didn't work well for me” gives Zed the chance to resolve any issues on their end in order to properly convert you, if you truly are interested in trying their editor. You don’t need to respond to the suggestion with a lecture on how companies exploit free volunteer labor and anything short of software served up on a silver platter would make you complicit. It’s really a little absurd.
If I had to guess, your system globally or their rendering library specifically is probably stuck on llvmpipe.
You don’t need a high-end gpu zed runs perfectly fine on embedded graphics. There are no shortage of software configurations on linux that result in cpu graphics rendering, which is the problem.
There is great enthusiasm for the editor in this thread. A personal anecdote indicating subpar performance on a common developer environment (Linux) is a useful signal that took a few seconds of effort.
Putting together a high quality, actionable bug report is a much higher bar that can often feel like screaming at the clouds.
So, only positive feedback allowed in this thread?
As a Linux user, I am sadly accustomed to some software working in only a just-so configuration. A datapoint that the software is still Mac first development is useful to know. Zed might still be worth trying, but I have to temper my enthusiasm from the headline announcement of, “everything is great”.
Is it even Zed’s fault if your linux system/setup over-eagerly prefers cpu rendered graphics because of old political and religious driver licensing issues?
I'm under Debian and i3wm/X11, sometimes it does some stuff that blocks input for a while so I can't drive the window manager until its done.
At least it did a month or so ago, and at that time I couldn't figure out a practical use for the LLM-integration either so I kind of just went back to dumb old vim and IDEA Ultimate.
When its fast its pretty snappy though. I recently put revisiting emacs on my todo-list, should add taking Zed out for another round as well.
I think that’s the same issue I’ve had with i3 and the sole reason why I switched to bspwm. I think it happens when the cursor is on a GPU accelerated window and you quit the app - it’s like i3’s keyboard input gets trapped in that pane and can’t escape (my work around was to create a terminal and kill the GPU app with skill using my mouse)
That sounds a lot like a CPU fallback of the rendering that should otherwise happen on the GPU. Isn't there any logs that could suggest that this is the case?
Edit: I just saw your edit to your reply here[1] and that's indeed what's happening. Now the question is “why does that happen?”.
That's interesting[1], what was slow when you tried it on MacOS?
[1]: people experiencing sluggishness on Linux are almost certainly hit by a bug that makes the rendering falls back to llvmpipe (that is CPU rendering) instead of Vulkan rendering, but MacOS shouldn't have this kind of problems.
there's basically zero documentation for Iced as it stands. They even wrote that if you're not a great Rust dev, you're going to have a bad time and that all docs are basically "read the code" until their book is written. I'm glad System76 is able to build using Iced, but you need a great manual for a tool to be considered mature and useful.
IMO Slint is milestones ahead and better. They've even built out solid extensions for using their UI DSL, and they have pages and pages of docs. Of course everything has tradeoffs, and their licensing is funky to me.
> what specific documentation do you think are lacking? Tutorials?
examples beyond tiny todo app/best practices would be a great start.
> Tutorials? That's for users to write.
sure, and how's that going for them? there are near zero tutorials out there, and as someone looking to build a desktop tool in rust, they've lost me. maybe i'm not important enough for them and their primary goal is to intellectually gatekeep this tool from the vast majority for a long time, in which case, mission accomplished
there are literally dozens of examples, including many apps you can reference. come join the discord and check out the showcase channel. I've written and published probably 50-100 examples to show best practices to people who want to learn more. I basically leave zero questions unanswered on that server, unless they are so far out of my wheelhouse that I can't answer them, but even then I might point you to the right resource or person...and I'm not even part of the team. the community is just wonderful IMHO
> sure, and how's that going for them? there are near zero tutorials out there, and as someone looking to build a desktop tool in rust, they've lost me. maybe i'm not important enough for them and their primary goal is to intellectually gatekeep this tool from the vast majority for a long time, in which case, mission accomplished
26.5k stars on github and a flourishing community of users, which grows noticeably larger every day. new features basically every week. bug fixes sometimes fixed in literal minutes.
it's not a matter of gatekeeping, but a matter of resources. iced is basically the brainchild of a single developer (plus core team members who tackle some bits and pieces of the codebase but not frequently), who already has a day time job and is doing this for free. would you rather him write documentation—which you and I could very well write—or keep adding features so the library can get to 1.0?
I encourage you to look for evidence that invalidates your biases, as I'm confident you'll find it. and you might just love the library and the community. I promise you a warm welcome when you join us on discord ;-)
here are a few examples of bigger apps you can reference:
> iced is basically the brainchild of a single developer (plus core team members who tackle some bits and pieces of the codebase but not frequently), who already has a day time job and is doing this for free.
This single-handedly convinced me not to rely on anything using Iced. I have no patience left for projects with that low a bus factor.
this is cool! i appreciate the warm invite. I really like your repo! They should include these examples in their primary repo. I did bump into halloy/icebreaker, etc but i just don't really find reading through massive repos a great entrypoint into whether a library/framework makes sense for me. I'll have to seriously look into it again, i do really like a vibrant community, and a lively discord is a nice close second. Thanks!
At some point you will need to realize that the endless people commenting about the lack of documentation is an issue with Iced, and the proverbial head in the sand approach will not help you.
UI frameworks typically need more than just the type of documentation that Rust docs provide. We see this with just about every UI framework around.
I'm not a maintainer or a member of the project, just an interested user.
Tutorials might be nice, but the library is evolving fast. I'm happier the core team spent time working on an animations API and debugging (including time travel) since the last release instead of working on guides for beginners.
Maybe that changes after 1.0.
Until then, countless users have learned to use it. Also iced is more a library than a framework. There's no right answer to the problems you'll be trying to solve, so writing guides on "best practices" is generally unhelpful if not downright harmful.
> Until then, countless users have learned to use it.
And countless others have requested exactly what I'm saying here. Cuts both ways.
> There's no right answer to the problems you'll be trying to solve
There's no right answer in e.g AppKit or UIKit, but having actual guides for those ecosystems has been crucial for their uptake/usage over the past decade or so. UI frameworks and libraries are not like standard developer tools and need additional documentation.
egui is nice but its API changes a lot between versions which makes it hard to rely on. Slint is stable and well documented. Its license is open source and also free to use in many cases so there is no real issue there.
> I can't wait until GPUI becomes a bit more mature/stable so I can build on top of it
I wouldn’t hold my breath. GPUI is built specifically for Zed. It is in its monorepo without separate releases and lots of breaking changes all the time. It is pretty tailored to making a text editor rather than being a reusable GUI framework.
That repo is to download a small template (why do we need a crate for that?), and it still pulls `gpui` directly from the Zed monorepo via a git dependency.
That kind of setup is fine for internal use, but it’s not how you'd structure a library meant for stable, external reuse. Until they split it out, version it properly, and stop breaking stuff all the time, it's hard to treat GPUI as a serious general-purpose option.
Firefox rendering is based on WebRender, which runs on OpenGL. The internals of WebRender are similar to gpui but with significantly more stuff to cover the landscape of CSS.
edit: they updated the AI panel! looking good!