Fantastic news. I've enjoyed using Zed on Mac for Go development, it just feels snappier than VSCode. I hope to try the Linux build over the weekend.
I am also tempted to try out their gpui library, might just cure my Rust aversion.
Zed on Linux Is Here
421–430 of 703 posts
Re: Zed on Linux Is Here
#422Earlier quoted context omitted.
You can however down the extension from the website and install it from the terminal. codium --install-extension {path to .vsix}
You are able to do so, but is it allowed by the website's terms of service? It may say that you are granted the license to extensions only with Microsoft builds of vscode. Microsoft isn't a stranger to distribution restrictions and software usage limitations. I remember uploading Visual C# Express 2010 (freely downloaded from Microsoft's website, without license keys) to a local file sharing website to ease the downl…
Terms of service? Who cares.
Re: Zed on Linux Is Here
#423Earlier quoted context omitted.
From their FAQ: We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as: Channels and calls Chat Channel notes We plan to allow offer our collaboration features to open source teams, free of charge. https://zed.dev/faq#how-will-you-make-money
Now see, I'm the opposite. I would like to pay a reasonable fee to drive a silver-and-oaken stake through the heart of the collab features. I will pay real money to just make it all go away. As others have said, I work in an environment with lots of different tools so collab stuff like this is just visual noise, let me turn it all off.
Maybe there will be forks that remove all the collaboration stuff. I can't imagine it'd be that hard.
Re: Zed on Linux Is Here
#424Ah, I'd love to try this. But I have a hard cross-platform requirement (Windows/Linux/MacOS) and I can't seem to get this running in WSL. Will keep checking if that improves in the future.
Windows builds are out there. You can build it yourself as well. They haven’t matured as much as Linux ones yet. But your requirement of portability is definitely fulfilled.
Re: Zed on Linux Is Here
#425Pretty nice to see aarch64 packages for so many distros. Sublime packages are x64 only, so this will go well with my Asahi setup
Re: Zed on Linux Is Here
#426I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…
A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me. VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.
I work with giant jsons every day and always have to fall back to nvim as vscode is terrible. Vscode even has a default size limit where it disables editor features for json files larger than a few megabytes.
Nvim works flawlessly tho even with syntax highlight and folding.
Re: Zed on Linux Is Here
#427There's much to like about Zed. Not only the technical parts, but also how transparently the communication is: https://zed.dev/blog/zed-is-now-open-source
To keep things simple yet powerful is the key to find their place in the market IMO. Don't know about the rendering speed (never had issues with other editor), but that's a bonus anyway.
Re: Zed on Linux Is Here
#428Earlier quoted context omitted.
Yeah, this was mostly my experience. The Zed editor was fast, but it just felt like it wasn't as good as other editors. For me, the version control integration was particularly poor - it shows some line information, but diffing, blame, committing, staging hunks, reviewing staged changes etc are all missing. There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For…
Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.
As I don't use either, can't you just open the file and look for
>>>> and <<<< and resolve them in whatever editor you need ? or do these editors do something else that helps with merge conflicts ?
Re: Zed on Linux Is Here
#429I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…
I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test. VSCode is very fast for me, when I open it in the morning and just starting my day . But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce sc…
Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature.
When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM).
I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.)
I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day.
I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months.
But VS Code has a very, very large lead in features, especially if you are working with TypeScript.
The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off.
The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config.
And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors.
So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things.
But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others.
So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking.
Re: Zed on Linux Is Here
#430Earlier quoted context omitted.
This makes me want to use Helix, because while I love the idea of a terminal editor, I'm not the kind of person to whittle away a day screwing around with my config files.
Helix has been stalled for a few months, and there are issues that make it frustrating to use at times. For example, :Ex and friends have been relegated to the plugin system (the root cause of the stall, it hasn't been merged). I still prefer it to the config overhead of nvim (as well as the kakoune-style movements!), but the paper cuts have hit a threshold and I've started writing my own text editor (I'd probably us…
The Helix community is the worst part about Helix. Especially the not so benevolent dictator of the project. Way too many comments like “if you don’t like how it’s done go use a different editor” instead of listening to feedback. That’s fine if they don’t care about adoption (they publicly say they don’t), but an actively hostile community doesn’t give me confidence in the editor, despite it being quite nice.