Readit NewsI'm very happy I went through the pain of setting everything up from scratch. It taught me how it all works. I just don't see how I'd get that same knowledge ever with Omarchy
Not everyone has a spare machine to tinker with.
With Omarchy you get a working good looking OS with thought out defaults and built in themes. It's ready to use, but can be customized.
That was years ago and I'm still on it.
Probably from people who have never used it.
Only ones that it can't is C/C++ (probably because that started as Apple only IDE) and .NET (that started as extension for Visual Studio).
They started Fleet that can do all of them, as a response for VS Code. But then came AI and Cursor probably took a large chunk of their users. So they redirected resources (like Zed that paused their collaborative features to focus on AI). There is currently a closed EAP for Cursor like ide based on Fleet. And their Git client as separate app.
Has this been true ever?
I was a customer for so many years. "One IDE to rule them all" and then they started cashing on more.
Progress was down to a crawl, performance down the shitter and bug reports go unnoticed for 2+ years.
VSCode poops on IntelliJ these days for everything but the UX; but with enough modding, it can be very close.
What are you talking about?
ReSharper came out 21 years ago 3 years after Intellij. RubyMine came out 15 years ago. 7 years before CLion.
> but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency
This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]...
> Rejected for device extension "VK_KHR_dynamic_rendering" not supported
Aha, ambitious devs >:) The dynamic rendering extension is pretty new, released with Vulkan 1.3. I suspect targeting Vulkan 1.1 or 1.2 might've been a little more straightforward than... rewriting everything to target DX11. Large games with custom engines (RDR2, Doom, Doom Eternal) were shipped before this was main-lined into Vulkan.
But thinking about it a little more, I suspect switching out the back-end to a dynamic rendering-esque one (which is why D3D11 rather than D3D12) was easier than reverting their Rust code to pre-dynamic rendering Vulkan CPU calls; the Rust code changes are comparatively light and the biggest change is the shader.
That being said, it's a bit annoying to manually write render-passes and subpasses, but it's not the worst thing, and more importantly extremely high performance is less critical here, as Zed is rendering text, not shading billions of triangles. The singular shader is also not necessarily the most complex[2]; a lot of it is window-clipping which Windows does for free.
> we had two implementations of our GPU shaders: one MSL implementation for macOS, and one WGSL implementation for Vulkan. To use DirectX 11, we had to create a third implementation in HLSL.
I wonder why HLSL wasn't adopted from the outset, given roughly 99.999% of shaders—which are mostly shipped with video games, which mostly target Windows—are written in HLSL, and then use dxc to target SPIR-V? HLSL is widely considered the best-specified, most feature-complete, and most documented shader language. I'm writing a Vulkan engine on Windows and Linux, and I only use HLSL. Additionally Vulkan runs on macOS with MoltenVK (and now 'KosmicKrisp'), but I suppose the Zed spirit is 'platform-native and nothing else'.
> symbolicating stack traces requires a .pdb file that is too large to ship to users as part of the installer.
Perhaps publishing a symbol server[3] is a good idea here, rather than users shipping dump files which may contain personally-identifiable information; users can then use WinDbg or Visual Studio to debug the release-mode Zed at their leisure.
[1]: https://github.com/zed-industries/zed/issues/35205
[2]: https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8b...
[3]: https://randomascii.wordpress.com/2020/03/14/creating-a-publ...