Hacker News Reader

Comment by volkk | Hacker News Reader

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.

edit: they updated the AI panel! looking good!

View on HN

> 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 think the AI panel is really bad compared to Cursor's

Have you had a chance to try the new panel? (The OP is announcing its launch today!)

It was available in their preview release for about a month: https://zed.dev/releases/preview

The annoncement is about it reaching prod release, but they emailed people to try it out in the preview version.

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!

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!

yeah it's dope. i love the "follow agent" feature as well

In the new agent panel not everything is editable. Maybe give it another try.

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.

The old one is still available! :D

Press the 3-dots menu in the upper right of the panel, and then choose "New Text Thread" instead of "New Thread".

Off topic: Fully editable AI chat conversation should really be the norm.

Editing and deleting not only your messages but also the LLM's messages should be trivial.

One of the coolest things about LLM tech is that it's stateless, yet we leave that value on the floor when UIs act like it's not.

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.

You can still access that one! Press the 3-dots menu in the upper right of the panel, and then choose "New Text Thread" instead of "New Thread".

Is it only fast on MacOS? I tried it on Linux and it was unusably slow. Seconds per frame instead of frames per second.

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?

Maybe, but no other application or editor has this problem. If all other apps work but Zed doesn't then it sounds like a Zed has an issue.

EDIT: just gave it a shot and I get "unsupported GPU" as an error, informing me that my GPU needs Vulkan support.

Their detection must be wrong because this is not true. And like I said, other applications don't have this problem.

The microcosm of a linux user played out so fast in that thread :P

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?

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.

It seem like bickering at this point, but I do not see how that is a useful signal.

I’m genuinely curious what you are getting out of it

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?

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.

> they're Zed's issues, not mine.

seems like you needing a GPU would be your issue

2025, when you need a high-end GPU for a text editor...

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.

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.

I had the same issue with my nvidia gpu but resolved it with the fix in this thread: https://github.com/zed-industries/zed/issues/14088

not sure why folks are downvoting you, but i'm not sure to be honest. i'm on an m3 pro

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)

it's not even fast on macOS in my experience

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.

Linux user here. I find Zed lightning fast compared to VSCode.

No issues on Linux for me. Much better (faster / snappier) than VS Code and forks.

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

[1]

I ran into the same issue (software rendering), pushed through to get it working, and it was worth it. It is extremely fast.

I'm on PopOS and the issue ended up being DRI_PRIME.

Might be worth trying `DRI_PRIME=0 zed`.

> because the other Rust GUI libraries/frameworks aren't great.

Iced, being used by System76's COSMIC EPOCH, is not great in what regards? Serious question.

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.

Then you should try egui. It has a lot of examples and it is among the most mature libraries along with iced and slint, without the licensing problems

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.

The crate is 100% documented. what specific documentation do you think are lacking? Tutorials? That's for users to write.

Calling iced not useful reads like an uninformed take

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

https://github.com/squidowl/halloy

https://github.com/hecrj/icebreaker

https://github.com/hecrj/holodeck

and my smaller-scale examples (I'm afraid my own big app is proprietary):

https://github.com/airstrike/iced_receipts a simple app showing how to manage multiple screens for CRUD-like flows

https://github.com/airstrike/pathfinder/ a simple app showing how to draw on a canvas

https://github.com/airstrike/iced_openai a barebones app showing how to make async requests

https://github.com/airstrike/tabular a somewhat complex custom widget example

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!

glad to hear it and thanks for the kind words!

I'll be waiting for you on Discord ;-) my username is the same there so ping me if you need anything

and I forgot to link to a ridiculously cool new feature that dropped last week: time travel debugging for free

https://github.com/iced-rs/iced/pull/2910

check out the third and fourth videos!

wow that's actually quite awesome

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

Can't please everyone

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.

Just write some tutorials already.

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.

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

i don't think that's quite true based on this repo: https://github.com/zed-industries/create-gpui-app

i think there's some desire from within zed to making this a real thing for others to reuse.

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.

i agree that it's currently too unstable, but the point was to show they have intent in others using it. maybe it'll be later

> because the other Rust GUI libraries/frameworks aren't great.

Waiting for Robius / Makepad to mature a bit more. Looks very promising.

I would love having gpui bingings for JS using NAPI, now using it from Rust is too slow, Rust feedback loop is too long

I am thinking if Firefox could adopt any of these.

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.

Honestly, miss me withy the AI shit. I just want an open-source Sublime Text that has first-class support for LSP.

You can not use it. I rarely do, but I love zed, it's fast and the LSP (rust and clangd in my case) just work

That's also Zed. You can turn off the AI features in the settings and a have a very fast, LSP-based editor.

Reply on news.ycombinator.com