Live data from Hacker News

We Have to Start Over: From Atom to Zed

zed.dev

131–140 of 243 posts

Re: We Have to Start Over: From Atom to Zed

#131
post #29

Earlier quoted context omitted.

This might be one of those things like monitor refresh rate where you can only really tell the difference if you've experienced the better version for a while, but I haven't ever felt slowed down by the speed of VS Code.

Every now and then I switch back to Apple's Terminal app, and I'm blown away at how much faster it is at just typing than iTerm it is, and how much nicer that is.

I switched to iTerm2 a few years ago due to blurry fonts on zoom with Terminal.app . Wonder if that's still a problem?

A few months ago I switched to WezTerm and, after some config wrestling, I've been very happy using it (https://github.com/bbkane/dotfiles/tree/master/wezterm).

Re: We Have to Start Over: From Atom to Zed

#132
post #10

Had a look at the About page, and the live coding feature does sound useful. I'm sure the guys are excited; it's a fun project. You get to write algorithms, optimise performance, and do GPU programming. But who needs another text editor that will probably never reach feature parity with Vim and a terminal multiplexer.

I would guess most developers do not use vim. Pretending that vim is the universally loved editor that every developer has agreed upon using seems pretty disconnected from the real world. VS Code came up out of nowhere pretty recently, and is used by a lot of people, so that shows that there is (or was, but still post-vim) opportunity for a new editor. Whether Zed is able to gain momentum to cater for the long-tail t…

Whether or not a large number of people use vim has no bearing on whether or not Zed will reach feature parity with it.

Re: We Have to Start Over: From Atom to Zed

#133

Earlier quoted context omitted.

[flagged]

From the current state of things, which to Voice Over is an empty window with no elements whatsoever, if they have thought about accessibility, they definitely don't consider it a priority. With such a monumental task, I'd be willing to excuse some slip-ups, but there was literally zero work put into this.

Saying “zero work out into this” and noting they didn’t prioritize it is different from implying they’re naive and unaware of how complex and intricate Accessibility can be. I’m not actually interested in whether they support it or not - I just think your comment is a poor and/or lazy attempt at dunking on them. It contributes to this site being less interesting discussion and turning it into /. 3.0.

(For what it’s worth, if I was building a next gen (attempt) at developer tooling, I would punt on Accessibility at the start as well. It sucks, but that’s such a smaller segment of the market that you don’t _need_ to serve immediately. It only matters that you eventually get there.)

Re: We Have to Start Over: From Atom to Zed

#134
post #57

Earlier quoted context omitted.

Vim is just an example. My point was that code at the end of the day is just text, and there's only so many features you need to be able to write/compile/edit efficiently in 99.9% of the cases. Any new power tools for text editing will end up taking more time to learn and remember than be of use.

I'm not so sure. The fact that were editing the code as text and not as mutations and annotations on its syntax tree has always struck me as a sign that we're still in the stone ages when it comes to expressing ourselves precisely to a computer.

The basic model of computation is the turing maching, and it’s a symbol manipulating one. So editing text is at the core of what computing is. You could go a step higher to edit tokens and that’s what VIM does, albeit imperfectly due to tokens not being a finite set.

Re: We Have to Start Over: From Atom to Zed

#135

I tried out the editor because of this post: it looks very promising. Unfortunately I can't use it because it doesn't have support for remote hosts/devcontiners. That feature of VScode is critical to my workflow, as I don't actually want to program on a Mac host, but rather use my Mac as a portal to the VMs and containers I actually code on. It massively helps with segmentation of my projects and improves my security…

I use development virtual machines to segment projects and clients also although I just run my editor in each VM. What's the benefit of the vscode remote hosts/dev containers over a normal remote session?

> I just run my editor in each VM

In addition to lag and a poor visual experience as others have mentioned, there's the issue of two (or more) operating systems with two separate shells/UIs. When using VMs or a VDI/remote desktop the cognitive overhead of remembering which OS shell I'm in for the purposes of keyboard shortcuts, clipboard, switching between programs and etc impacts my productivity significantly.

VSCode (or any other editor with similar features) shell is great because it completely separates the editor environment from the dev environment. I can run as many instances of VSCode as I want each with their isolated dev environment of the target host, but all managed by one shell, one window manager and one clipboard.

Re: We Have to Start Over: From Atom to Zed

#136

Earlier quoted context omitted.

From the current state of things, which to Voice Over is an empty window with no elements whatsoever, if they have thought about accessibility, they definitely don't consider it a priority. With such a monumental task, I'd be willing to excuse some slip-ups, but there was literally zero work put into this.

Saying “zero work out into this” and noting they didn’t prioritize it is different from implying they’re naive and unaware of how complex and intricate Accessibility can be. I’m not actually interested in whether they support it or not - I just think your comment is a poor and/or lazy attempt at dunking on them. It contributes to this site being less interesting discussion and turning it into /. 3.0. (For what it’s w…

Also, even if they did use native widgets that come with integrated accessibility features, would those actually work as intended for a multi user collaborative editor like Zed?

Imagine a group of four people live collaborating on a file in Zed. How do you present the actions that are being taken by everyone so that a screen reader can understand what is going on?

Mute everyone except the user? Speak every keystroke pressed by everyone all of the time? Announce line changes made by others when they pause for a while / when they move to another line?

In short, I think if accessibility for screen readers were to happen for Zed it would take a monumental amount of effort to make it usable, regardless of whether they are using native widgets or not.

Re: We Have to Start Over: From Atom to Zed

#137
As a lowly web developer I must not know what i'm missing, can anyone explain what the issue is with an array being a list of references? Why is there a chase going on, is someone trying to get away?

> JavaScript is... You think you have an array of objects, but you really have an array of pointers to objects. So every single time you're walking over that, you're chasing it down.

Re: We Have to Start Over: From Atom to Zed

#138

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this in a custom framework without sacrificing performance won't be easy and is going to require lots of messy, per-platform work. It's not like it's optional for them either. It would be for a simple editor that you can just decide not to use, but they're positioni…

I'm not surprised that most of rust guis are not a11y friendly, there is no established gui library yet, none of them I would call mature yet

Not long ago there weren't any gui libraries that wouldn't be just binding to existing C framework or was in proof of concept state of lifecycle

I'm sure this situation will improve in the future and I understand frustration of someone that rely on a11y features, but you need to understand that everyone first will try to achieve solid gui library before will start adding accessable functionality

Re: We Have to Start Over: From Atom to Zed

#139

As a lowly web developer I must not know what i'm missing, can anyone explain what the issue is with an array being a list of references? Why is there a chase going on, is someone trying to get away? > JavaScript is... You think you have an array of objects, but you really have an array of pointers to objects. So every single time you're walking over that, you're chasing it down.

Pointer chasing, bad for cache locality.

Re: We Have to Start Over: From Atom to Zed

#140

As a lowly web developer I must not know what i'm missing, can anyone explain what the issue is with an array being a list of references? Why is there a chase going on, is someone trying to get away? > JavaScript is... You think you have an array of objects, but you really have an array of pointers to objects. So every single time you're walking over that, you're chasing it down.

Pointer chasing, bad for cache locality.

ah, that closes the loop for me, thanks
Post reply on HN