Zed Code Editor Making Progress On Linux Support

[jacob]

I never used Zed, what are its main selling points against VSCode? I mean other than "no MS telemetry", while I absolutely share that concern, there is the Codium build that has the telemetry removed.

[F.Ultra]

The entire blog post is a must read and should be yet another example of shame for Linux.

And their solution to just support Ubuntu is the correct one . In fact I council everyone I meet who is interested in developing for Linux to just set it in their mind that when you think Linux you think Ubuntu and nothing else. I also tell them to package your Ubuntu app three ways. tarball, .deb, Snap. That way if anyone in the “Never Ubuntu” camp gets butt hurt their hobby project distribution didn’t get your app just for them they can always take the tarball and run with it. Make it into a RPM, a Flatpak or a Gentoo port. But let them carry that load for wanting to stay outside the Ubuntu world. It’s high time to ostracize the wider Linux world from Ubuntu with the exception that the app you’re working on is more of a server, HPC, or like kind of app then of course make an RPM version for Red Hat and Suse. Otherwise let the twiddle geeks twiddle over to their console and twiddle with the tarball. They’re used to it by now as it’s a badge of geek honor.

It only reads that way if you have zero clue on how things really work. Very little of what is described there are problems are just decisions that one have to make on a platform that is diverse when you as a dev comes from a walled garden like macOS. The whole issue of distribution is e.g them just overthinking it, simply release as a statically linked binary in a tarball or as a flat right now and since you are open source simply let the various distros handle the actual distribution in their own way once you get to a stable state.

[luno]

The entire blog post is a must read and should be yet another example of shame for Linux.

And their solution to just support Ubuntu is the correct one . In fact I council everyone I meet who is interested in developing for Linux to just set it in their mind that when you think Linux you think Ubuntu and nothing else. I also tell them to package your Ubuntu app three ways. tarball, .deb, Snap. That way if anyone in the “Never Ubuntu” camp gets butt hurt their hobby project distribution didn’t get your app just for them they can always take the tarball and run with it. Make it into a RPM, a Flatpak or a Gentoo port. But let them carry that load for wanting to stay outside the Ubuntu world. It’s high time to ostracize the wider Linux world from Ubuntu with the exception that the app you’re working on is more of a server, HPC, or like kind of app then of course make an RPM version for Red Hat and Suse. Otherwise let the twiddle geeks twiddle over to their console and twiddle with the tarball. They’re used to it by now as it’s a badge of geek honor.

snap packaging is such a joy, it might be best. They improved its startup performance too. The most users who don't care that about linux just use ubuntu, for them Linux = Ubuntu, WSL Ubuntu have huge userbase maybe more than whole Desktop Linux users. maybe Gaming companies should partner with Canonical for better anticheat system which works signed kernel, Crowdstrike already does lot of stuffs like anticheat

[piotrj3]

I never used Zed, what are its main selling points against VSCode? I mean other than "no MS telemetry", while I absolutely share that concern, there is the Codium build that has the telemetry removed.

According to Zed dev claims, huge performance difference. Zed is on par performance wise with Sublime. Memory footprint half of that comparing to VScode.

[jacob]

According to Zed dev claims, huge performance difference. Zed is on par performance wise with Sublime. Memory footprint half of that comparing to VScode.

Meh. I don't really see the point of that. VSCode/Codium runs perfectly on any modern laptop or even RPi, not even mentioning any actual serious development workstation. I'm not saying that Zed is not interesting, but hopefully it has something better to offer. It's not the 1980s any more, trying to save every kB of memory and every CPU cycle is definitely not a thing nowadays. For the software you are developing, it can be, if it's embedded or designed for some other uber-constrained environment. But for the development environment itself, there's objectively hardly any merit especially if using Rust, C++ or Java, when the mere compilation and build process is an enormously memory and CPU intensive task.

[Ironmask]

I never used Zed, what are its main selling points against VSCode? I mean other than "no MS telemetry", while I absolutely share that concern, there is the Codium build that has the telemetry removed.

I think people's interests are just more about the technical side of it than anything. It's a cool project and it's cool how they implemented it, but it's actual usefulness is something we're yet to see once it's cross-platform versions release. It's also less of an "editor for the sake of it" since it was made intentionally to tie into macOS' API.
To be honest, I'm not sure how far any editor would get these days if they're not built on a browser engine like VSCode is. I don't use VSCode's browser functionality myself or develop anything web-related, but, a lot of development these days involves at least some browser work, whether you're making a browser-based frontend for an application or you're making an Electron app in itself. Heck, a major part of VSCode's success is that you could view web pages in it. I feel like not having that functionality baked into an editor is an Achilles heel these days.
Pardon me for digressing, but I kind of view the web browser as filling the gap for GUIs left between TUIs and websites. When developing a console application, there's nothing to it, just print to stdout. You can use fancy frameworks, but it's all just stdout. Same for making a website, use any fancy framework you want, but it's just HTML/CSS/JS (and soon to simplify as WASM and WGPU). But making a GUI? Ha, have fun, either pick your poison with a single toolkit or try supporting the dozen or so in popular use today (exactly what the Zed team are complaining about in their blog post). It's unreasonable, and why a lot of developers either fall back to TUI or make a website frontend or electron app.
So, yeah, I don't see an editor without browser viewing functionality to get very far. I sure hope it gets traction, but, it's at a disadvantage.

[jacob]

I think people's interests are just more about the technical side of it than anything. It's a cool project and it's cool how they implemented it, but it's actual usefulness is something we're yet to see once it's cross-platform versions release. It's also less of an "editor for the sake of it" since it was made intentionally to tie into macOS' API.
To be honest, I'm not sure how far any editor would get these days if they're not built on a browser engine like VSCode is. I don't use VSCode's browser functionality myself or develop anything web-related, but, a lot of development these days involves at least some browser work, whether you're making a browser-based frontend for an application or you're making an Electron app in itself. Heck, a major part of VSCode's success is that you could view web pages in it. I feel like not having that functionality baked into an editor is an Achilles heel these days.
Pardon me for digressing, but I kind of view the web browser as filling the gap for GUIs left between TUIs and websites. When developing a console application, there's nothing to it, just print to stdout. You can use fancy frameworks, but it's all just stdout. Same for making a website, use any fancy framework you want, but it's just HTML/CSS/JS (and soon to simplify as WASM and WGPU). But making a GUI? Ha, have fun, either pick your poison with a single toolkit or try supporting the dozen or so in popular use today (exactly what the Zed team are complaining about in their blog post). It's unreasonable, and why a lot of developers either fall back to TUI or make a website frontend or electron app.
So, yeah, I don't see an editor without browser viewing functionality to get very far. I sure hope it gets traction, but, it's at a disadvantage.

Depends what you are doing. I personally don't really do any web development work, but I appreciate VSCode's rich ecosystem of extensions and for Rust in particular it's by far the best IDE/editor available thanks to its top-notch integration with rust-analyzer. Not all languages are on the same boat obviously, but Rust code can get complex and hard to understand at times, and showing the inferred types inline, the go-to-definition and documentation one click away, the integration of the debugger and cargo and other goodies really make a huge difference in comfort, and therefore productivity. One of the biggest criticisms against Rust are its infamous compilation times and VSCode's support, I would say, takes 75% of that problem away by pointing out problems virtually as you type. I actually wish there was more competition on that front. But let's rephrase the question: having never used Zed, does it have some advantages over basic editors like GNOME Edit for the simple editing of text files or, at the other end of the spectrum, does it do for some language what VSCode does for Rust?

[bug77]

Not sure why you need GPU acceleration to edit text, but at least it's not another electron monstrosity.

[aksdb]

Meh. I don't really see the point of that. VSCode/Codium runs perfectly on any modern laptop or even RPi, not even mentioning any actual serious development workstation. I'm not saying that Zed is not interesting, but hopefully it has something better to offer. It's not the 1980s any more, trying to save every kB of memory and every CPU cycle is definitely not a thing nowadays. For the software you are developing, it can be, if it's embedded or designed for some other uber-constrained environment. But for the development environment itself, there's objectively hardly any merit especially if using Rust, C++ or Java, when the mere compilation and build process is an enormously memory and CPU intensive task.

The less my editor/IDE and other tools use, the more I have for peaks by the compiler/linker/toolchain.

As someone who frequently has multiple IDEs open (Goland, IDEA, WebStorm) and can easily run in situations where I don't have enough memory over to actually compile the project. When the gradle build needs 15GB of memory, it makes a difference if the IDE is also hogging on 10GB or if it is fine with something around 1GB.

[Old Grouch]

In fact I council everyone I meet ...

The word is counsel not council.