Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

311–320 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#311
post #273

Earlier quoted context omitted.

What is the plugin you are waiting on?

Not OP but I can’t leave jet brains until a double shift search everywhere is implemented.

i dont use jetbrains products but you can map the command palette or the file search to double shift and have it function the same way. zed supports key chords for bindings perfectly well. just do "shift shift" and it should work

Re: Zed editor switching graphics lib from blade to wgpu

#312

Earlier quoted context omitted.

Iced.rs is probably the better UI library anyways in the long run as it’s backed by a major hardware vendor. https://iced.rs

There is also Slint : https://slint.dev They are also backed by a company, and have kept a stable 1.x release for some time.

Slint is essentially proprietary-only. Licensing a library as GPLv3 severely limits where it can or should be used.

Re: Zed editor switching graphics lib from blade to wgpu

#313
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

Ever chase a segfault that happened through a callback called by the GUI framework? The promise of Rust is to eliminate that. Wrapping a C library implies unsafe Rust which can't do that. It's genuinely pleasant to develop thing with that baseline robustness.

Re: Zed editor switching graphics lib from blade to wgpu

#314
post #59

Earlier quoted context omitted.

A lot of people use VSCode. Zed's value proposition is being basically that but with fully native code, so without the madness that is Electron. If you're not a fan of this kind of tooling, it's totally fine, but many people see the value in having an extensible graphical code editor

Is Zed really fully native? Last time I tried it (few months back) it felt really slow. Truns out it was spawning nodejs servers and using tons of memory. Honestly, vscode was much faster for me (and looked much better).

[deleted]

Re: Zed editor switching graphics lib from blade to wgpu

#315
post #192

Earlier quoted context omitted.

Iced.rs is probably the better UI library anyways in the long run as it’s backed by a major hardware vendor. https://iced.rs

Iced seems really promising, however, it's a passion project by a single developer. They very clearly stated that their goal is to follow their passions and desires first, everyone else second, and that it will always be a single person project. Their readme even discourages contributions. Companies using it in production are often forking it as a result, and trying to keep their fork in sync. Ultimately, if the comm…

This is silly. Definitely use Iced.rs, no one cares about it’s early pre-1.0 state. It has good fundamentals and is easy to use. 99% of people on here aren’t building anything more than a vanity project anyways.

Re: Zed editor switching graphics lib from blade to wgpu

#316

Earlier quoted context omitted.

Not OP but I can’t leave jet brains until a double shift search everywhere is implemented.

i dont use jetbrains products but you can map the command palette or the file search to double shift and have it function the same way. zed supports key chords for bindings perfectly well. just do "shift shift" and it should work

Default double shift in zed goes to Execute a command window, sadly it doesn't support file searching within the same window and that's what I suppose he meant. I know cause I'm an avid JetBrains fanboy too and I can't use any other IDE because of that and few other features. Also, they're working on Search Anywhere Jet-Brains style feature right now if you believe Github Issues.

Re: Zed editor switching graphics lib from blade to wgpu

#317

Earlier quoted context omitted.

> Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what. LSPs, they are snagging the LSPs made by other developers for languages you are using. if you install any LSP or language support in VSCode its running the same thing. It only installs when you are using a language that has default support such as Rust, Python (which I believe uses a Nod…

So basically there is no getting away from javascript runtime. So why should I use zed instead of vscode then?

Latency, FPS, efficiency. The LSPs while beefy, are not part of the overall efficiency and are used as sub processes, so if they fail or are sluggish, they won't affect how the editor runs, if you don't want to use LSPs, then you can go ahead and disable those.

Zed is one of the few editors, that like Sublime, are really focused on efficiency, using minimal resources (when needed) and the latency and FPS of the editor is bounds better than VS Code. It just works, better.

Re: Zed editor switching graphics lib from blade to wgpu

#318
post #30

Earlier quoted context omitted.

I'd love to read a writeup of the state of Rust GUI and the ecosystem if you could point me at one.

https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-... I started writing a program that needed to have a table with 1 million rows. This means it needs to be virtualised. Pretty common in GUI libraries. The only Rust GUI library I found that could do this easily was gpui-component ( https://github.com/longbridge/gpui-component ). It also renders text crisply (rules out egui), looks nice with the default styl…

> * Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.

Have you seen their intro that also has an image viewer building tutorial?

https://publish.obsidian.md/makepad-docs/Makepad+Introductio...

Re: Zed editor switching graphics lib from blade to wgpu

#319
The GUI situation for Rust is dire. We are still not GUI yet! Even if Rust isn't the best for GUI, the opportunity is still there. Qt is the best option. There isn't a second option. Don't let Go and Zig have bindings for Qt without Rust! Only Rust. Only Cargo. No QML. No C++. No markup. No immediate mode. No dead projects.

Re: Zed editor switching graphics lib from blade to wgpu

#320

Earlier quoted context omitted.

From what I see wgpu isn’t using the same font stack as chromium. I think the Rust community would be against those dependencies. You can just convert bitmap fonts, supporting them doesn’t make sense in 2026.

wgpu is an API for rendering stuff on the GPU, it has no concept of font stacks or text rendering.

I was talking about glyphon, wgpu-text, etc.
Post reply on HN