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

Zed: High-performance AI Code Editor

zed.dev

Post reply on HN
Print view View original

441–447 of 447 posts

Re: Zed: High-performance AI Code Editor

#441

Post by nsonha »

tiffanyh wrote: post #123

Slightly OT: Why aren't AI coding assistants implemented as plugins (like through an LSP), rather than being a standalone AI-first editor (like Cursor)? I might be missing the obvious, and I get no standard exists, but why aren't AI coding assistants just plugins?

If you actually look it up you'll see more of them that are plugins than full editors.

I don't actually know their thinking but I know that for the VSCode ones (fork or extension), I tend to have at least 2 AIs at any point in time and compare them in my daily work. Probably when this field matures, lock-in will be more common, and you need control of the entire editor for that.

Re: Zed: High-performance AI Code Editor

#442

Post by nsonha »

deliriumchn wrote: post #130

I hate the direction they're going to be honest with this giga focus on AI bullshit. Only good part added was zeta (their own predictive editing model that jumps across the file where it predicts you want to edit your typo etc AND have a "subtle" mode), but they price it at 20/month, which is absurd.

That zeta thing you describe is in every AI tool these days.

Re: Zed: High-performance AI Code Editor

#443

Post by amai »

Before implementing AI they should rather improve basic stuff like git support and a good debugger. Jetbrains git support and debugger are best in class. No other editor/IDE comes close. So I will stay with IntelliJ an PyCharm for now.

Re: Zed: High-performance AI Code Editor

#444

Post by oblio »

vanviegen wrote: post #274
lispisok wrote: post #272

Earlier quoted context omitted.

People have been using editors that look comparable for decades that dont need fancy GPU rendering to be fast and responsive. What is happening that stuff like that is necessary now?

GPU rendering in some form or another (mostly just bitblitting characters, I guess) has also been common for decades. Classic hardware text mode is basically just that. Also, display densities and sizes have gone up (for some of us).

> Classic hardware text mode is basically just that.

I highly doubt that, unless you consider bitblting to be hardware accelerated.

When people say "GPU render" they mean 3D accelerators from the line of Voodoo onwards, not regular 2D graphics cards.

Re: Zed: High-performance AI Code Editor

#445

Post by Klonoar »

airstrike wrote: post #371
Klonoar wrote: post #361

Earlier quoted context omitted.

At some point you will need to realize that the endless people commenting about the lack of documentation is an issue with Iced, and the proverbial head in the sand approach will not help you. UI frameworks typically need more than just the type of documentation that Rust docs provide. We see this with just about every UI framework around. Just write some tutorials already.

I'm not a maintainer or a member of the project, just an interested user. Tutorials might be nice, but the library is evolving fast. I'm happier the core team spent time working on an animations API and debugging (including time travel) since the last release instead of working on guides for beginners. Maybe that changes after 1.0. Until then, countless users have learned to use it. Also iced is more a library than a…

> Until then, countless users have learned to use it.

And countless others have requested exactly what I'm saying here. Cuts both ways.

> There's no right answer to the problems you'll be trying to solve

There's no right answer in e.g AppKit or UIKit, but having actual guides for those ecosystems has been crucial for their uptake/usage over the past decade or so. UI frameworks and libraries are not like standard developer tools and need additional documentation.

Re: Zed: High-performance AI Code Editor

#446

Post by naikrovek »

EnPissant wrote: post #357
naikrovek wrote: post #163

Earlier quoted context omitted.

native resolution on any monitor should work fine on MacOS. using pixel fonts on any non-integer multiplier of the native resolution will always result in horrible font rendering, I don't care what OS you're on. I use MacOS on all kinds of displays as I move throughout the day, some of them are 1x, some are 2x, and some are somewhere in between. using a vector font in Zed looks fine on all of them. It did not look fi…

macOS fonts subjectively look terrible and objectively look blurry on normal resolution monitors because: 1) No hinting 2) No subpixel rendering

Both hinting and subpixel rendering are things on MacOS. MacOS just doesn’t color the pixel for LCDs like Windows does, because the GUI on MacOS is resolution independent.

It is greyscale font rendering, yes, but it is coloring those pixels based on subpixel information.

Post reply on HN