In this episode of Zed Decoded, Thorsten talks to Mikayla, who's been leading the effort to Zed working on Linux, about the Zed's Linux version and how it's taking shape
It’s open source, and they already said they were Mac only because they used Metal for rendering. It’s not suspicious for devs to use what they’re most familiar with.
Is there any particular problem with MoltenVK? As I see it, it’s by far the best solution for cross platform software on macOS in need of graphical hardware acceleration.
There’s nothing wrong with the software itself. It works great for what it does. On the other hand, it’s a compatibility layer, which always increases friction between things a little. I think the best use for this is running legacy software.
There aren’t many alternatives. Maybe in the future, we’ll see graphics API abstraction libraries like wgpu get used more. This gives developers a single API which can use DirectX on Windows, Vulkan on Linux, or Metal on macOS. This could allow support for entirely new graphics APIs without developers using it having to do anything.
Of course, that’s my opinion. People can build their software how they like.
Yeah, even Asahi has better OpenGL support than real macOS. They make damn sure you have to use Metal to get the most out of it, just like eventually you get caught up in DirectX on Windows whether you want it or not. You can use Vulkan and OpenGL, but the OS really wants to work with Metal/DirectX buffers in the end.
I appreciate that the devs care enough to make it really good from the start, because that sets the benchmark. Now the Linux version has to have a similar enough polish to it.
In comparison, Atom and VSCode both worked fine on Linux just about day one thanks to Electron, but it was also widely disliked for the poor performance. It’s a part of what Zed competes on, performance compared to VSCode.
they already said they were Mac only because they used Metal for rendering
And you say:
Metal is basically the only graphics API on Mac
So they’re on Mac bc they need Metal, but they picked Metal bc they’re on a Mac? It’s circular and friggin weird man
Not to mention there are cross-platform wrappers that will pick from all three depending on system - some that are very prolific among Rust devs (Zed is coded in Rust) like wgpu, for instance. They could’ve used wgpu and supported all 3 from the get-go and it would be easier than doing Metal anyway!
And so picking just Mac and/or Metal first is suspicious.
While I generally agree with your skeptical attitude toward this, I think the fact that they were targeting Apple’s Metal graphics API to built the most performant possible IDE makes sense. You can’t just snap your fingers and have a Linux graphical stack start working with your software.
I think the reason they targeted macOS first is probably because many of the dev team uses Macs.
As a Linux user, I’ll happily wait for software like this to get ported to native Linux APIs so we get performant text editors instead of more Electron crap.
As a die-hard Linux user, I understand that most of their devs probably used Macs. Sadly, they are likely not an outlier which means many ( most ) of their target customers are Mac users too.
Overall, I applaud their focus and platform native approach. Let’s hope we get a decent Linux editor out of it at some point.
I was kinda referencing warp, a supposedly new terminal that was also written in Rust, had AI stuff, started on Mac, and finally got a Linux version, which lasted 30 seconds on my computer once I saw there is no option to use it unless you make an account. Yes. For a LOCAL terminal. Nuts.
Somehow all these OSS projects that start with only a Mac client seem so suspicious to me…
I wonder if they will enforce a login to use the software?
It’s open source, and they already said they were Mac only because they used Metal for rendering. It’s not suspicious for devs to use what they’re most familiar with.
That in itself is a suspicious choice tbh
What’s suspicious about it…?
Using metal over Vulcan is a terrible choice for oss projects in my mind. Closed ecosystems extend all the way to the rendering pipeline
Until you actually try to use Vulkan on macOS. Since there’s no native support, you end up needing MoltenVK.
That’s on apple, if they want devs they should support industry standard frameworks
Not the best point to make while you are questioning why they are building Zed. Bot maybe?
You mean the brand new editor with <1% of the market, that zed?
But… they have devs. A lot of software is written for OSX. Zed being one of them. You may not like it, but it works for Apple.
Is there any particular problem with MoltenVK? As I see it, it’s by far the best solution for cross platform software on macOS in need of graphical hardware acceleration.
There’s nothing wrong with the software itself. It works great for what it does. On the other hand, it’s a compatibility layer, which always increases friction between things a little. I think the best use for this is running legacy software.
There aren’t many alternatives. Maybe in the future, we’ll see graphics API abstraction libraries like wgpu get used more. This gives developers a single API which can use DirectX on Windows, Vulkan on Linux, or Metal on macOS. This could allow support for entirely new graphics APIs without developers using it having to do anything.
Of course, that’s my opinion. People can build their software how they like.
No idea, especially since MacOS has limited OpenGL support and no Vulkan support, Metal is basically the only graphics API on Mac
Yeah, even Asahi has better OpenGL support than real macOS. They make damn sure you have to use Metal to get the most out of it, just like eventually you get caught up in DirectX on Windows whether you want it or not. You can use Vulkan and OpenGL, but the OS really wants to work with Metal/DirectX buffers in the end.
I appreciate that the devs care enough to make it really good from the start, because that sets the benchmark. Now the Linux version has to have a similar enough polish to it.
In comparison, Atom and VSCode both worked fine on Linux just about day one thanks to Electron, but it was also widely disliked for the poor performance. It’s a part of what Zed competes on, performance compared to VSCode.
The other guy mentioned:
And you say:
So they’re on Mac bc they need Metal, but they picked Metal bc they’re on a Mac? It’s circular and friggin weird man
Not to mention there are cross-platform wrappers that will pick from all three depending on system - some that are very prolific among Rust devs (Zed is coded in Rust) like wgpu, for instance. They could’ve used wgpu and supported all 3 from the get-go and it would be easier than doing Metal anyway!
And so picking just Mac and/or Metal first is suspicious.
While I generally agree with your skeptical attitude toward this, I think the fact that they were targeting Apple’s Metal graphics API to built the most performant possible IDE makes sense. You can’t just snap your fingers and have a Linux graphical stack start working with your software.
I think the reason they targeted macOS first is probably because many of the dev team uses Macs.
As a Linux user, I’ll happily wait for software like this to get ported to native Linux APIs so we get performant text editors instead of more Electron crap.
As a die-hard Linux user, I understand that most of their devs probably used Macs. Sadly, they are likely not an outlier which means many ( most ) of their target customers are Mac users too.
Overall, I applaud their focus and platform native approach. Let’s hope we get a decent Linux editor out of it at some point.
They start with Mac clients because those devs use Macs.
I was kinda referencing warp, a supposedly new terminal that was also written in Rust, had AI stuff, started on Mac, and finally got a Linux version, which lasted 30 seconds on my computer once I saw there is no option to use it unless you make an account. Yes. For a LOCAL terminal. Nuts.