Live data from Hacker News

Zed on Linux Is Here

zed.dev

491–500 of 703 posts

Re: Zed on Linux Is Here

#491
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…

I have had to open the parent folder of all the different code bases I need in a single VSCode window, instead of having an individual window for each. I much prefer having individual windows for each code base, but the 32G of ram for my laptop is not enough to do that. If I were to run multiple instances of VSCode, then the moment I need to share my screen or run specs some of them will start crashing due to OOM.

I don't notice much of a problem from multiple windows. I sometimes have a dozen going.

It's the language extensions in the windows that can cause me problems e.g. rust-analyzer is currently using more than 10GB! If windows are just for reading code and I'm feeling some memory pressure then I kill the language server / disable the extension for that window.

I have more problems with jetbrains. 64GB isn't enough for a dev machine to work on 10s of Mbs of code any more...

Re: Zed on Linux Is Here

#492

I 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 don't know what's on zed/VSCode and what's on the TS language server. Microsoft's latest embrace-extend-extinguish strategy is keeping just enough special sauce in (frequently closed-source) vscode extensions and out of the language servers. They do the same thing with Pyright/Pylance.

TS itself is lock-in. I mean, the entire point of JS is that it's portable, and there's certainly no lack of compile-to-JS languages that are already finished and have much more powerful type systems and existing libs/ecosystems.

Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well.

But the infanterists in our profession manage to get it wrong, every single time.

Re: Zed on Linux Is Here

#493

I 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…

In the morning vscode is ok, come noon, it’s the primary thing eating my battery and it’s getting slower and slower; day end it’s unusable. Sure, restart it, I know, but it’s fairly terrible though.

I've never experienced this. Have you tried disabling all your extensions to see if one of them is causing it?

Re: Zed on Linux Is Here

#494
Zed's focus on high performance might be misplaced. Compared to editors like VSCode, the performance boost feels marginal. To convince developers to switch, the emphasis should be on enhancing the overall developer experience. Marginal speed gains alone aren't enough to make me move away from VSCode, and I don't care if a tool is written in Rust or any other language.

Re: Zed on Linux Is Here

#495
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…

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.

Re: Zed on Linux Is Here

#496
post #88

Man, I'm conflicted. I mean, Zed works pretty damn well. So far my biggest annoyance with Zed though is that it's constantly trying to download language servers and other tools and run them. And sure, that's handy, but 1. I don't really want it, I'd much rather only use distribution-provided tools. 2. It doesn't work at all on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to…

And with that all my interest is gone and I won’t bother with zed.

I highly recommend Little Snitch or opensnitch to protect oneself from rogue developers. Yes, anybody downloading things or uploading things without my consent is a rogue.

Re: Zed on Linux Is Here

#497
post #263

I 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…

It's a Prisoners's Dilemma. Since apps are evaluated in an isolated fashion there is an incentive to use all the resources available to appear as performant as possible. There is further incentive to be as feature-rich as possible to appeal to the biggest audience reachable.

That this is detrimental to the overall outcome is not unfortunate.

Re: Zed on Linux Is Here

#498

I 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…

Hah, similar here. I keep trying it out after seeing posts here and there, but I can't seem to switch from VSCode.

For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.

Re: Zed on Linux Is Here

#499
post #429
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…

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 benchmarking. It's open source so you don't me afraid looking under the hood to see what's happening.

> I'll save a file and it will be like jank...jank... File Save participants running with a progress bar.

I don't see that at all. Saving is instant/transparent to me.

There is so much possible configuration that could cause an issue e.g. if you have "check on save" from an an extension then you enter "js jank land" where plugins take plugins that take plugins all configured in files with dozens of options, weird rules that change format every 6 months e.g. your linter might take plug-ins from your formatter, your test framework, your ui test framework, hot reload framework, your bundler, your transpile targets...

If saving is really slow then I would suspect something like an extension is wandering around node_modules. Probing file access when you see jank might reveal that.

Re: Zed on Linux Is Here

#500
post #486
post #473

Earlier quoted context omitted.

> In summary: our modern computer's sheer power are camouflaging poor software performance I somewhat disagree. Features sell the product, not performance[1], and for most of the software development you could count on the rising CPU tide to lift all poorly performing apps. But now the tides have turned to drought and optimizing makes a hell of a lot of sense. [1] They are more of a negative sell and relative to othe…

performance is a feature.

Yes, but more in a QoL way. I say negative as in - if you don't have it you lose a customer, rather than if you have it, you gain a customer.

If performance is a feature, then it's not an important feature. Otherwise, people would use Paint, for everything.

Or put it another way, you want to do X1 task. It's editing a picture to remove some blemishes from skin. You could use a console, to edit individuals pixels, but it would take months/year to finish the task if you are making changes blindly, then checking. It could take several days if you are doing it with Paint. Or you could do it with Photoshop in a few minutes. What difference does a few ms make if you lose hours?

Now this is only task X1 which is edit blemishes, now you do this for every conceivable task and do an average. What percent of that task are ms loses?

Post reply on HN