Hey! Engineer at Zed here. Linux port is on our roadmap. Hopefully we'll get it done this year!
Nope, it's using Apple's proprietary Metal API.
https://survey.stackoverflow.co/2023/#section-most-popular-t...
Stackoverflow found that Linux and macOS is the slight majority for professional use and the minority for personal use with developers (with the caveat that the total professional use of all categories is >100%)
I have been on MacOS the last 8 years or so but before that was all Windows and Linux. I prefer MacOS now but curious what I am missing. My colleagues that are using Windows machines all use WSL with dev containers so really just using Linux under the hood.
My experience is that pretty much everything is cross platform these days. I don’t do .Net or game dev though. Just Go, Java and some NodeJS these days.
Yeah, but with Windows GUI along with fractional scaling, device, and etc support haha. I've developed on both bare Linux and for years in Linux VMs. Saying Windows+WSL is "really just linux under the hood" does this setup a massive disservice. It makes me smile every time I type WSL into the terminal lol.
Was just curious what Windows only tools I am missing out on.
"We will let you know when windows support is under development. The Zed team isn't taking feedback on when we start on windows support, nor why we didn't start with windows.
The amount of people on each platform isn't relevant, as it starts with the base assumption that more people = better to the Zed team. Growth driven development unlikely to lead to a resilient, high quality product long term."
A company like Jetbrains can do this to an extent due to existing products fueling long term R&D efforts before they bare fruit. Interested to see how this outlook holds up as the runway burns and investor pressure increases from that cool 12.5m they raised last year.
Even if it weren’t a toss up and significantly more devs used windows, deciding to target windows based solely on OS market share is one of the worst things a small dev team with finite resources could do. It’s just not a compelling argument at all.
About 80% of the developers at my company do the same. Only a few are happy with just Windows.
So, I would prefer if they prioritize Linux and leave Windows as the last one.
There’s lots of reasons to not choose windows as a first release platform, and it being ‘the most common development platform’ isn’t a compelling one, especially for a small team with finite resources.
These days that's a lot less of a concern than it used to be. It is a lot of up-front work to facade e.g. Metal, Vulkan (and even D3D12) but it's much much much easier than back in OpenGL vs D3D9/10 days.
Most of the general concepts are more or less the same across them all these days. The "shapes" of the APIs are very similar.
A texture is a texture is a texture. Same for a vertex/index/uniform buffer, vertex/fragment/compute shaders (notably not geometry, but you can just use compute), etc.
Unfortunately, graphics is in many ways the easy part. Really excellent integration with system menus, preferences, keyboard, input method editing, all have more variation across platforms and a still-evolving story of solid Rust abstractions. Lately, we've decided to try joining forces with the winit project to see if we can get those problems solved well.
so, my strong suspicion is that porting gpui is the long pole, since it is apparently just going to do its own gui toolkit
Do it proper like emacs tramp so it will connect to any platforms/architectures.
More generally, targeting another project's complete featureset is often a great way to get mired down in the wrong details. Unless you can afford to do a proper cleanroom -- then, you'll be able to at least match the performance and useful abstractions used in the original.
Remote SSH + Dev Containers and their seamless integration (even stacking one on the other) are the only features that keep me using VS Code. I would love to see the full implementation of these in an editor as fast and light weight as Zed.
Fwiw, I do a lot of infrastructure-as-code, full stack, and systems programming.
I usually have a split screen (editor | terminal) or two terminals on the side, and exec into a container, or use devenv.sh.
If I _really_ need to modify files in the container as I dev and a "make" doesn't cut it, I usually just run podman with a -v mount. Similarly for remote machines w/ sshfs, though I try not to.
Similarly, editing code in-place over SSH rather than rsyncing back and forwards is very useful for certain types of embedded development. I worked for a while on sensor systems where a lot of the logic was handled by a Python webserver that couldn't really run without access to the sensor data it was using. Developing entirely locally was therefore difficult, but developing on the machine was also painful because it didn't have the right tools. So we'd work locally, and then copy the Python files over every so often and restart the server. At the time, I don't think VSCode's remote stuff was working as well, but I believe now it's a lot better and could have handled that situation well - edit everything in-place, run it immediately, but still have the power of you local development machine available to you.
Wha...? This is a killer feature. I'll put up with a lot of crap to use it. That doesn't mean I wouldn't switch to something nicer in other ways if it also offered this killer feature.
It's hard for me to understand why there are IDEs under active development not trying to offer this feature. It is so much better an experience to have the network split into the proper place: between the UI and the heavy computation. Having the UI too far away undoes whatever responsiveness work has been done and more. Having the heavy computation too near means it's hard to develop and test the far environment, take advantage of its compute, etc.
almost all my coding these days is over vsc-ssh. if zed supported sshing into a remote host and into a docker container as seamlessly as I can in vscode, Id switch immediately. The performance of the ui in zed is so much better. I'm a bit sad I can't switch with its current feature set.
You want to target FreeBSD? Linux on POWER or RISC-V? An old (ARMV6-TDMI) Raspberry Pi? Sorry, no remote work for you.
They are not an apple and pears comparison...
Did you have to build it from source?
Their UI framework is also rendering via the GPU, so it's more likely they'd wrap it in a GTK/Qt/whatever window and then just render accordingly. You don't need GNUStep for it since there's little "mac"-isms you need to cover.