Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

Post reply on HN
Print view View original

181–190 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#181

Post by roflcopter69 »

eklavya wrote: post #69
badhorseman wrote: post #50

The Zed editor seems kind of silly to me. I would rather my editor works in many possible environments maybe even one that only has a tty interface. What advantages are people finding with this editor other then high fidelity scrolling.

I wanted to check the hype, so I installed Zed and opened a go project. Ram usage: VS Code 580 MB Zed 410 MB I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.

How much of the RAM usage is by gopls (The Go LSP)?

Re: Zed editor switching graphics lib from blade to wgpu

#183

Post by net_ »

doodlesdev wrote: post #171
net_ wrote: post #145

Earlier quoted context omitted.

I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.

> I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL. > I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually. Well, that's why :) For most serious applications, accessibility isn't a second thought, it's a requirement and it's very hard to implement c…

So the solution is to build applications around less of a common base? I don't follow the logic, with respect to Zed. I get what you mean if there's a first-party UI solution in your language (e.g. Swift), but in that case you don't need an open-source UI library.

Re: Zed editor switching graphics lib from blade to wgpu

#184

Post by nu11ptr »

satvikpendem wrote: post #176
nu11ptr wrote: post #174

Earlier quoted context omitted.

Thanks. I probably could have answered my own question had I simply looked here: https://github.com/gpui-ce/gpui-ce/pulls and here: https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...

Sadly it doesn't actually look like gpui-ce has any activity, the maintainer merged one pull request (literally, #1) and then stopped. They should've just added more community maintainers to the GPUI repo directly rather than having a fork.

Yeah, why fork and create confusion if you don't plan to do anything with it?

Re: Zed editor switching graphics lib from blade to wgpu

#185

Post by staticassertion »

laweijfmvo wrote: post #104
satvikpendem wrote: post #42

Zed also stopped GPUI (their GPU accelerated Rust UI framework) development for now, sadly. > Hey y'all, GPUI develoment is getting some major brakes put on it. We gotta focus on some business relevant work in 2026, and so I'm going to be pushing off anything that isn't directly related to Zed's use case from now on. However, Nate, former employee #1 at Zed, has started a little side repo that people can keep iterati…

> We gotta focus on some business relevant work in 2026 Remember that post announcing the millions of VC capital they raised? This is the result

You vastly overestimate the amount of pressure a board can place on an early stage startup. The far more likely scenario to me (someone who raised VC money) is that the CEO likely looked at their run rate and decided to prioritize things more aggressively. This is hardly surprising and it has nothing to do with VCs.

Re: Zed editor switching graphics lib from blade to wgpu

#186

Post by piker »

osener wrote: post #161
piker wrote: post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

> We ignore for these purposes Zed's GPUI which the Zed team has transparently, and understandably abandoned as an open source endeavour Do you have a source for this?

The Zed team said it themselves. There is a direct quote in the parent thread.

Re: Zed editor switching graphics lib from blade to wgpu

#187

Post by iamnbutler »

satvikpendem wrote: post #42

Zed also stopped GPUI (their GPU accelerated Rust UI framework) development for now, sadly. > Hey y'all, GPUI develoment is getting some major brakes put on it. We gotta focus on some business relevant work in 2026, and so I'm going to be pushing off anything that isn't directly related to Zed's use case from now on. However, Nate, former employee #1 at Zed, has started a little side repo that people can keep iterati…

I started the gpui-ce fork but I'm becoming somewhat more interested in a fresh framework that is more aligned with the rust ecosystem in general - using crates like glam/glamour, parley, palette, etc

Lots of gpui was built with build Zed/a text editor in mind directly, and as folks have mentioned here, it is hard for Zed Industries to justify work on gpui that is purely for the community. Nathan is usually pretty pragmatic around not optimizing early, and gpui is generally serving Zed's needs at the moment (from what I know, I haven't worked on Zed since July)

I do think ZI would generally benefit if gpui did get pulled out of Zed if there was a community that was passionate about taking it over... but that is time and effort in itself.

Re: Zed editor switching graphics lib from blade to wgpu

#188

Post by staticassertion »

KingOfCoders wrote: post #111

Switched from Intellij (various) to Cursor because of AI integration, only using Claude Code CLI, switched to VS because Cursor became so annoying every release, pushing their agents down my throat, activating what I did deactivate every release, recently thought "Why do I even use that slow bloated thing of VS?" and switched to Zed. Very happy camper. So much faster. So much snappier. Would love Claude Code CLI inte…

Yeah, I find Zed to be strictly the best experience for "I actually want a pleasant editor" experience. Using it reminds me of when I finally switched from nano to sublime as a freshman.

Re: Zed editor switching graphics lib from blade to wgpu

#189

Post by staticassertion »

nmilo wrote: post #94

I find it odd the rust community feels the need to reimplement tried and tested APIs in "pure safe Rust". Like no other language has better C integration, and we have had cross-platform windowing libraries since like the 90's, why does everyone reach for a brand new unstable libraries with less maintainer support? Edit: replying to https://tritium.legal/blog/desktop , not the OP

My very weak understanding is that a lot of the C/C++ libraries heavily leverage concepts like inheritance that don't map well to Rust, and so a lot of the GPU work has been "how do we actually make this an idiomatic API?" and that has required more experimentation.

AFAIK people 100% are using other libraries for UI, but often use a macro or something to force Rust to behave in a way that those libraries expect.

I haven't read about this in literally years, but that's my recollection.

Re: Zed editor switching graphics lib from blade to wgpu

#190

Post by miguel_martin »

net_ wrote: post #129

In 2020, I started working on a (C++) game engine. Since the only decent open-source UI option was Dear ImGui (which was obviously a bad choice for consumer-facing UIs), I ended up rolling my own retained-mode UI library on top of SDL. Now, it's fully-featured enough that I rarely have to touch it. There's even a major company using it for embedded products. I don't get why every language's community doesn't just do…

SDL is not perfect, e.g. you can't get pinch/zoom events on MacOS. IMO, using the OS APIs yourself is better.
Post reply on HN