Live data from Hacker News

Zed is our office

zed.dev

61–70 of 343 posts

Re: Zed is our office

#61
post #19

I love Zed. I, mostly, love the direction they are taking the editor in. But. There are now two times I see Zed going in the wrong direction. The AI integration was one. This feels like the wrong direction again. I never really liked the AI integration. It felt off to me. I do love coding with Claude and I think I know why. It presents the "information I need to know" in a way my puny brain can handle it. Colored dif…

Man, Im like the total opposite in terms of preferring the Zed UI vs claude code. I really try to avoid raw claude when possible. I very rarely pull it up to do concurrent sessions when I have Zed open already working on something else. Or if I need to do something quick while in the CLI in a random directory. Otherwise, I think just the "files modified" feature is worth using Zed as the primary interface.

You make some good points, and I need to revisit Zed+AI to see where things are at. This probably proves you are a better developer than me.

But, also, after reading your comments, I'm just not sure I need an "editor" anymore. I love that I can npm install claude anywhere. Zed does not exist for ARM servers yet, but I can install claude there, and it can troubleshoot my database connections, and edit code, and grep files. Those are all the things I used an editor for, because an editor has better ergonomics than using the CLI. I'm sad to say "misspelled prompts" might have better ergonomics for me.

Re: Zed is our office

#62

If you've been a developer long enough, you might recall the teletype package for Atom—both built by Zed's founders. I first experienced this in SubEthaEdit in 2013 or so, but it has been around since the early 2000s : Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for…

SubEthaEdit was a very inspiring software project for me. The fact that a small team could, in a few months, produce an amazing app that solved real problems and gained notoriety was amazing. As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster. I'm also a fan of Zed and everything they're doing, but it's notable that shipping next-gen editor software…

> it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.

Yes I agree but so many things that might seem "done" (and in someways I think software/SaaS as an ecosystem is "done" compared to where we came from).

BUT - so many companies just bloat themselves and their products. I think the end of ZIRP is going to have an effect on that (more enshitification / rent seeking for sure) and I think there will be an opportunity to iterate and make copyware that doesn't take the higher development efforts.

We really need a winning electron alternative that is more resource friendly. That, IMO, will be a big game changer and I know there are lots of promising alternatives already.

Re: Zed is our office

#63

If you've been a developer long enough, you might recall the teletype package for Atom—both built by Zed's founders. I first experienced this in SubEthaEdit in 2013 or so, but it has been around since the early 2000s : Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for…

People have been doing collaborative text editing since the 60s actually! See, The Mother Of All Demos[0], referenced in our first blog post[1] :D

I'd say CRDTs are also a big change. CRDTs make live collaboration much more robust for all parties involved, and they only started to reach maturity in the mid-late 2010s

[0] https://en.wikipedia.org/wiki/The_Mother_of_All_Demos

[1] https://zed.dev/blog/crdts

Re: Zed is our office

#64

Earlier quoted context omitted.

Zed is the only modern IDE-like editor which is fast enough to replace (n)vim for me. I plan to use it for more and more projects, but I've had minor issues with it's Vi-mode. I'll always remain someone plugged into vim because I need it sometimes when shelled over a terminal. Editing files over SSH can work with editor support, but is often less reliable or fast than jumping through whatever hoops I need to to get a…

Incidentally, I use Vim for editing files via SSH as you do, or if I'm in WSL, but haven't figured out how to use it for projects!

I just have a few plugins which help. Mainly the LSP for gotodef and popovers for type info, etc. This was what finally made me transition to neovim. Also a tree viewer, Startify, and :Rg for ripgrep integration. Those are my big ones.

Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.

Re: Zed is our office

#65
post #53
post #35

Earlier quoted context omitted.

Counter argument to living software is that it treats "never done" products as a virtue instead of a failure of design. Here's a thread where the person replying to me makes this case: https://news.ycombinator.com/item?id=45455963

I love it when I have a tool that’s “done” but the software I work on in my career is never, ever done. It’s almost like there’s two different things we call “software”. there are tools like, idk, “curl” where you can use and old version and be happy. and there are interactive organizations in the world, like, eg, Hacker News, which mutates as the community’s needs change

Software for evolving business-needs is the same for me. What's insightful is that we (I) take continuously evolving software as just that: evolving. It's a defacto virtue to continuously tinker.

Doing away with check-ins entirely is the extreme end-game of that pov. I'm in product and every day and every week yes we very much continually change the product!

But I'm growing less convinced that the natural end-state of this methodology produces obviously better results.

Re: Zed is our office

#67

Zed is lovely and I hope it becomes super successful but this kind of mass collaboration might be ok for meeting minutes... maybe. But thinking of it for coding it gives me shingles. Code by mass live committee. Yikes.

Pair programming can be really great. Or horrible. Depends entirely on the people. This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.

> code-walks

it's probably subjective, but I find these collaboration features can be overused for this kind of thing.

If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.

I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.

Re: Zed is our office

#69

I _really really_ want to try this feature, but only if I can selfhost the collaboration server. If there is any way to do this, it's not obvious. Given that as I understand it, lots of project details will pass through Zed's servers, I can't imagine any enterprises would knowingly allow this without some kind of SLA with Zed.

It could be easier, but it is supported AFAIK: https://github.com/zed-industries/zed/issues/8260#issuecomme...

Unfortunately, we no longer support self hosting. We're planning on reintroducing it once we've polished the single player experience a bit more :)

Re: Zed is our office

#70
post #21

I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software

Imagine if someone clicks the deploy button when you're in the middle of typing something and then the service goes down due to a syntax error. To prevent this, we will need some sort of way to set a global lock to indicate that "I'm not done typing yet" and you can only deploy once everyone has released this lock.
Post reply on HN