Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed on Linux Is Here

zed.dev

Post reply on HN
Print view View original

521–530 of 703 posts

Re: Zed on Linux Is Here

#521

Post by palata »

oneshtein wrote: post #476
hyperbrainer wrote: post #450

Earlier quoted context omitted.

Completely agree. Furthermore, you could always just not pipe it to sh, read it first if you care so much. Releasing and maintaining packages across a range of distros is extremely hard and time consuming, and they just released the linux version.

It's time consuming only if author interested in good UX. If author wants to use their users as alpha-testers, then he can spent a minimal amount of time on packaging.

Given that it's open source, it's not the authors' problem to package it. You can package it for your distro, or wait for someone to do it.

It will be better because you presumably use it. Chances are that the authors don't use the same distro as you do, so they are not in a good position to make a package for you.

Re: Zed on Linux Is Here

#522

Post by tankenmate »

vmfunction wrote: post #411
j1elo wrote: post #263

Earlier quoted context omitted.

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…

> In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks. Same can be said about a lightweight web page and 'React' with tons…

This is giving me flashbacks to editors of yore; EMACS, Eight MB And Continually Swapping. I remember reading almost the exact same comments on Usenet from the 80s and 90s.

Re: Zed on Linux Is Here

#523

Post by elbear »

satvikpendem wrote: post #225
the_duke wrote: post #81

Earlier quoted context omitted.

I think people just have very different tolerances for latency and slowness. I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it. I tried out Zed and it actually feels fast enough for me to consider switching.

Zed is still quite a bit slower than Neovim in my experience.

Interesting. That tells me there's something wrong with my neovim config. When I open a file for the first time, it takes some time before it shows the contents of the file. It's not even a big config, but maybe I'm using a plugin that slows things down or something.

Re: Zed on Linux Is Here

#524

Post by satvikpendem »

elbear wrote: post #523
satvikpendem wrote: post #225

Earlier quoted context omitted.

Zed is still quite a bit slower than Neovim in my experience.

Interesting. That tells me there's something wrong with my neovim config. When I open a file for the first time, it takes some time before it shows the contents of the file. It's not even a big config, but maybe I'm using a plugin that slows things down or something.

Try using Neovim without loading a config, just like a fresh install, and see how it is.

Re: Zed on Linux Is Here

#525

Post by BaudouinVH »

If I understand correctly I need a graphical card - my current linux laptop does not have one. Until I upgrade to a newer model I will uninstall my copy of zed.dev - couldn't even launch it.

Re: Zed on Linux Is Here

#526

Post by veidr »

Fluorescence wrote: post #499
veidr wrote: post #429

Earlier quoted context omitted.

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…

Vscode is very snappy for me on less powerful machine Ryzen 3900 (Ubuntu, X-windows). I have a good experience running multiple instances, big workspaces and 70+ actively used extensions and even more that I selectively enable when I want them. It's only the MS C# support that behaves poorly for me (intentional sabotage?!). I wonder if you have some problem on your machine/setup? I'd investigate it - try some benchma…

I have that kind of fast, smooth experience with VS Code, too - but that is when I open my small hobby monorepo, or only when I don't leave it open all day. When I open a big work monorepo (250k files, maybe 10GB in size, or 200MB when you exclude all the node_modules and cache dirs, the slowness isn't instant but it becomes slow after "a while" — an hour, or two.

I do actually regularly benchmark it and test with no/minimal extensions, because I share responsibility for tooling for my team, but the fact that it takes an hour or two to repro makes that sort of too cumbersome to do. (We don't mandate using any specific editor, either, but most of my team uses VS Code so I am always trying to help solve pain points if I can.)

And its not just the file saves that become slow — it's anything, or seemingly so. Like building the auto-import suggestions, or jumping to the definition by ⌘-clicking a Symbol. Right after launch, its snappy. After 2-3 hours and a couple hundred files having been opened, it's click, wait, wait... jump.

Eventually, even typing will lag or stutter. Quitting and restarting it brings it back to snappy-ish for a while.

It is true that maybe we have some configuration that I don't change, so even with no or minimal extensions, there might be something about our setup triggers the problems. Like we have a few settings defined at the monorepo root. But very few.

    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {},
But before you think aha! the formatter! know that I have tried every formatter under the sun over the past 5 years. (Because Prettier gave my team a lot of problems. Although we now use it again.)

We have a huge spelling dictionary. I regularly disable the spelling extension though, but what if there was an edge case bug where having more than 1000 entries in your "cSpell.words" caused a memory leak on every settings lookup, even when the extension wasn't running? I mean... it's software, anything is possible.

But I suspect it is the built-in support for TypeScript itself, and that yeah, as you work with a very large number of files it has to build out a model of the connections between apps and libs and that just causes everything to slow down.

But then, like I mentioned nothing else I've seen quite has the depth of TypeScript support. Or the core set of killer features (to us), which is mainly the remote/SSH stuff for offloading the actual dev env to some beefy machine down the hall (or across the globe).

To us, these things are worth just having to restart the app every few hours. It's kinda annoying, sure, but the feature set is truly fantastic.

Re: Zed on Linux Is Here

#527

Post by ostwilkens »

neurobashing wrote: post #375
saratogacx wrote: post #297

Earlier 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.

I have been able to disable+hide every element of the Zed UI which I don't have use for, so far.

Re: Zed on Linux Is Here

#528

Post by paride5745 »

slim wrote: post #458
paride5745 wrote: post #448

Earlier quoted context omitted.

Indeed! Just release a flatpak, even a snap. I’m not asking to support all distros. But at least one between flatpak and snap is enough to support pretty much all distros out there in a clean manner, not with curl | sh

but then I will need curl | sh to install snap :(

lol

good stuff snap is in pretty much any distro repo out there :D

Re: Zed on Linux Is Here

#529

Post by j1elo »

lynx23 wrote: post #495
vmfunction wrote: post #411

Earlier quoted context omitted.

> In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks. Same can be said about a lightweight web page and 'React' with tons…

That brings a Python "performance" talk to mind that I was recently listening to on YouTube. The first point the presenter brought up was that he thinks the laptops of developers need to be more modern for Python to not be so slow. I had to stop the video right there, because this attitude isn't going anywhere.

You know what? I actually believe in having developers work (or maybe just test) with slower computers (when writing native apps) or with crippled networking (when doing web) in order to force them consider the real-world cases of not being in a confy office with top-notch computers and ultra high-bandwidth connections for testing.

Re: Zed on Linux Is Here

#530

Post by veidr »

I do not get the focus on collaborative editing (surely niche?) while the Remote Development in VS Code (in which "remote" can mean in a docker container running on your local Docker, or a container elsewhere, or a whole-ass other computer you own, or a rented computer/instance in le cloude) seems like such a more game-changing feature, similar in some ways but probably less work.

And make that the thing you charge for. ¯\_(ಠ_ಠ)_/¯

Post reply on HN