I suppose ideally you'd want it to be written on Linux first, if you're that kinda person - but the market is probably on Mac?
I remember reading a long time ago (think pre-intel macs) that game developers never developed for macs. However if they did, the games would sell because the mac people wanted games and there were so few available they would buy anything. problems of a closed ecosystem.
Because Macs are expensive (in absolute terms) Mac users are a self-selected group who are willing to spend money. Linux users have high standards and are not willing to spend money. For a text editor in particular Linux is going to be the toughest market because it's already pretty saturated.
Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long te…
wgpu (and webgpu more generally) is often presented as a very good choice for a cross platform low level graphics api. but it was designed around safety/security constraints to support the web, sometimes at the cost of performance (my understanding) i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level…
Roughly yes, though I'd caveat it with the specific application of the GPU: simple, 2D, UI elements. We've already built an abstraction that allows us to fluently build up a design, and then burn it down into a collection of rectangles, paths, images, and such. We're not dealing with particle effects, lighting, 3D models, or anything else that game engines need to consider. As such, it's a lot lower cost for us to use something like Vulkan or DX12 directly. And, in fact, that was the backup plan if we didn't find something like Blade that we where happy with.
> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…
MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.
Molten VK is amazing. When I started working with it, I was expecting a lot of caveats and compromises, but it's shockingly similar to just using Vulkan that you can easily forget that there's a compatibility tool in play.
Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)
If Apple had just adopted the Vulkan standard instead of going off with their own proprietary graphics API this would have been a non-issue. Smacks of Canonical and their repeatedly doing one thing while ignoring the rest of the community standardizing on something else.
Metal predates Vulkan. But also I'm pretty sure Apple doesn't care if an app is portable.
In fact they probably care that it's not easily portable
> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…
Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.
Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.
I'm curious why Zed chose Blade over wgpu/wgpu-hal. There's a bit of detail here: https://github.com/zed-industries/zed/issues/7015 But I'd be curious to read a longer writeup on the tradeoffs and how they came to their decision.
This is a pretty good answer: https://github.com/gfx-rs/wgpu/tree/trunk/wgpu-hal The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
> The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that.
The page you linked clearly states that wgpu-hal's API is extremely unsafe and skips many checks in order to reduce overhead. So while "secure and sandboxed" explains why wgpu wasn't chosen, it doesn't explain why wgpu-hal wasn't chosen.
From how they've been talking about Zed (on The Changelog, among other places), I expected to be wowed on my first open of the application, but the experience kind of fell flat for me. I might try it again when they have some better onboarding, though!
I really appreciate how Zed tries to tailor make and ensure their app looks and feels native on Linux. One thing that scares me with it though is the lock in of the multiplayer features. I can see it forcing me to use it and not my preferred editor, because other people use Zed. Would love it if we were not only platform independent but also editor independent regardless of social pressure.
I use Zed as a daily driver, and I haven't once used the collaborative features
If you care a lot about Linux support, Lapce is a very promising alternative. Much like Zed, it also is written in Rust with native GPU-based rendering and a shared focus on enabling integration with modern IDE technologies such as LSP servers, tree-sitter parsers and DAP for debugging.
I didn't realize this was basically an ad for an IDE.
I thought this was some component. Lol, yeah if your IDE doesnt work on Linux, the problem is your IDE, not linux.