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

531–540 of 703 posts

Re: Zed on Linux Is Here

#531

Post by MrBuddyCasino »

dcchambers wrote: post #181

However silly it is, I've always hated the aesthetics of VS Code. I know it's themeable but despite that the overall look and feel just isn't right on MacOS or Linux. That side bar drives me crazy. I find that out-of-the-box Zed is much prettier and feels more native than VS Code. But for a tool that we spend hours using each day, how it looks and makes you feel really matters. I am enjoying experimenting with Zed. I…

> However silly it is, I've always hated the aesthetics of VS Code.

Thank god I'm not alone. Besides being unsightly, it also looks like a toy.

Re: Zed on Linux Is Here

#532

Post by j1elo »

Ygg2 wrote: post #500
rouxz wrote: post #486

Earlier quoted context omitted.

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…

> if you don't have it you lose a customer, rather than if you have it, you gain a customer

I completely agree with that take. That's exactly the reason why, for example, whenever I'm about to do some "Real Work" with my computer (read: heavyweight stuff), all Electron apps are the first to go away.

My work uses Slack for communications, and it is fine sitting there for the most part, but I close it when doing some demanding tasks because it takes an unreasonable amount of resources for what it is, a glorified chat client.

Re: Zed on Linux Is Here

#534

Post by lynx23 »

j1elo wrote: post #529
lynx23 wrote: post #495

Earlier quoted context omitted.

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.

I totally agree. However, I feel like this is an ageism :-) Are you 40+ perhaps :-)

Re: Zed on Linux Is Here

#535

Post by doublerabbit »

pilif wrote: post #457
kaba0 wrote: post #452

Earlier quoted context omitted.

But linux [1] has absolutely zero security measures, and this has basically free reign over your computer to send off your .ssh folder, your browser cache, to install a permanent keylogger, etc. [1] Standard “GNU”/linux desktops

True, but where's the difference between downloading a binary and executing it vs. downloading a script and executing that which will then download a binary and execute it? In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine. Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it? That's super great. That has saved…

> where's the difference between downloading a binary and executing it vs. downloading a script and executing

The difference is that the attack vector of the shell script is an easier target.

If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the script could go for days undetected.

With the executable you can compare the checksum and with the whole package compiled it is less prone and more tricky to alter.

Unless that script is under monitoring 24/7, I'm going for binary but they don't support BSD anyway.

Re: Zed on Linux Is Here

#536

Post by mintplant »

rustyminnow wrote: post #285
mintplant wrote: post #226

Earlier quoted context omitted.

Similarly, I have unlimited persistent per-file undo turned on in Neovim. I can open any file I've edited previously and walk through the full history of how it got there. With Undotree [0], I can even navigate branching paths in development. I don't know how people live without this. [0] https://github.com/mbbill/undotree

What are your undo settings? I set undofile and undodir, but not sure if it's unlimited. One issue I have is if nvim is closed and the file is touched by some outside process (say git pull) it clobbers the history. Do you know if there's a fix to that?

re: undo settings, I set my `undolevels` [0] to a very high number to make it unlimited for all intents and purposes.

[0] https://vimdoc.sourceforge.net/htmldoc/options.html#'undolev...

Re: Zed on Linux Is Here

#537

Post by foldr »

chillfox wrote: post #416
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…

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.

Like the sibling, I have no problem with keeping multiple windows open and I only have 16GB RAM (MacBook Pro). It must be language extensions or something like that.

Re: Zed on Linux Is Here

#538

Post by foldr »

jay_kyburz wrote: post #332
scblock wrote: post #317

Earlier quoted context omitted.

A typical 60 Hz screen refresh is 16.7 ms

If you haven't tried a 144hz or even a 240hz gaming PC, you should. You can really feel the difference dragging things around the screen. (I'm not sure I would notice typing, but for dragging windows around I could never go back to 60fps.)

I do not notice any difference between my 120Hz work MacBook Pro and my 60Hz home MacBook Air. I might notice if I did a side-by-side comparison and looked closely. But why would I?

Re: Zed on Linux Is Here

#539

Post by n_plus_1_acc »

KETHERCORTEX wrote: post #309
vorticalbox wrote: post #126

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

I don't remember ging to the Website and agreeing to anything. I got vscodium from my package manager.

Re: Zed on Linux Is Here

#540

Post by avianlyric »

handsaway wrote: post #26

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…

> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.

Post reply on HN