Hey! Thank you for this cool editor! However, has it been written with cross-platform support in mind? Otherwise, porting from mac to linux could be rather painful and time-consuming... Will there be an ETA for us linux users? I saw it on the roadmap [0] but without an ETA.
"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."
Haha, well they will get lots of feedback they don't want to take.
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.
From what I can find, the used OS of software developers is 61% windows, 46% Mac so this argument has no weight on the considerations the team should make Å— it’s essentially a toss up.
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.
I think linux + osx combined is probably developer majority. I'm assuming most Windows development is .NET or Unity based. Over the past nine years, I've worked primarily with Node, Ruby, and a smidgen of Java and no employer has issued Windows machine. It's in sharp contrast with the start of my career where I was in VB6 and C# where I only worked with Windows environments. Could be confirmation bias, though.
Windows is a great platform for developing any language or platform, not just .Net. Personally I think it blows macOS and its dated tools out of the water in any category
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%)
Just curious what tools are you missing on MacOS or Linux that are found on Windows?
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.
Yeah Linux desktop environments are a bit of a mess but OP specifically called out MacOS as well. Once you add Rectangle it is a solid DE in my opinion. Also it is Unix/linux compatible so kind of the same beast with good GUI/hardware and *nix terminal.
Was just curious what Windows only tools I am missing out on.
I agree. Long time Linux engineer who prefers Windows to OSX as a desktop OS. Currently use a Windows workstation with WSL and VSCode as a daily driver. I feel this currently gets me the best of both worlds(Windows/Linux).
It is, but barely (windows is @ 61%, macOS is at 46% based on the numbers I found). And even if we ignore that, number of potential users is far from the only factor you’d consider when choosing the first platform to target for a new project. And then, ignoring that as well, just because an OS has more potential users in total, that doesn’t mean it has more potential users of your editor.
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.
I'm not in the graphics world at all, but I read this lively discussion last week (post [0], discussion [1]) that made me think the situation was pretty messy. Is it maybe not as bad as that makes it appear?
I'd recommend wgpu. It should be a fairly easy migration from Metal, as Apple has been actively involved in the design, and there are similar concerns for developer experience (unlike, say, Vulkan).
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.
“Please don’t do it like a 4x4 truck, do it proper, like a bicycle” — there is some overlap between those things, but for people who are actually making full use of the former, the latter is not a useful suggestion
I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
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.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
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.
How exactly are these features present in your workflow? I honestly struggle to think of when I'd ever use this.
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.
Devcontainers are amazing for getting a consistent environment set up on multiple computers on multiple operating systems. I was in this situation recently with a new colleague who was using a very locked-down Windows computer, and it was really convenient for the "you must install" list to be Docker and VSCode only. It's definitely not ideal - it adds overhead on Windows and Mac, there's occasional networking issues, and I don't have all the creature comforts of my usual shell - but it's very convenient for what it is.
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.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
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.
> the people who make "full use" of vsc-over-ssh are satisfied with vscode,
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.
The former is bad design, it has no gradual fallback and works in a terrifying way. It pulls binaries from MS servers and runs a headless vscode instance on the remote machine.
You are dead in the water if you target a machine/architecture it doesnt support.
You want to target FreeBSD? Linux on POWER or RISC-V? An old (ARMV6-TDMI) Raspberry Pi? Sorry, no remote work for you.
I'd very much prefer something that works seamlessly in 95% of the use cases and makes me do some work or look for an alternative for the remaining 5%, than something that makes me do work in 100% of the cases.
Bikes likewise have advantages that 4x4s lack. If you mean to imply everyone ought to be satisfied with the 4x4, and not ask for a bicycle: no. We can have both.
I don't think I would like that. I haven't been impressed with the experience of running GUI apps within WSL. Weird window controls/resizing, compositing, and font rendering issues would be a hard blocker from using this as probably the second most important app on my computer.
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.
Speaking of Linux, are there any other editors we can use today? I tried to look for one recently but couldn't find anything. (edit: I mean collaborative editors)
Precisely, I'm looking for collaborative editors. Thanks for the suggestion, I hadn't seen this one.
Unfortunately, it seems that this plugin only shares the editor window and does not keep a local copy of the files. I was wishing for something that would let both sides run & compile the code during the editing session, without having to stop for git push.
https://github.com/MicrosoftDocs/live-share/issues/3524
Jetbrains allows both users to execute / debug but it’s all on the host machine.
What you’re talking about sounds like you should do an rsync script that watches file changes, but seems like a good way to constantly be breaking the other persons workflow.
git solves these problems- feels like the right tool. But maybe I’m missing something about your workflow
Looking for collaborative editors in particular. Two people editing at once, on different computers. Each person has their own copy of the file, on disk.
Authoring Latex documents. I want a non-browser alternative to Overleaf. When the paper is close to done, me and my colleague are on voice call, editing the same file. But we both want to be able to compile it to PDF, to be able to see the figures.
Gobby is mostly dead but still works. Win/Linux; macOS builds have gotten harder now that it's been about 3 years since the last release: https://gobby.github.io/
EDIT: It's apparently on Macports as of quite recently, though the port health for recent macOS releases looks bad.
I was particularly looking for collaborative editing; two people editing the same file at once and each has a local copy of the file so they can run the code. Perhaps one could use a normal editor for this if there were some underlying command-line tool and/or plugin to do the actual file synchronization. Do you know of any?
