[HN Gopher] Zed is our office
___________________________________________________________________
Zed is our office
Author : sagacity
Score : 410 points
Date : 2025-11-13 15:41 UTC (7 hours ago)
(HTM) web link (zed.dev)
(TXT) w3m dump (zed.dev)
| bguthrie wrote:
| I hadn't realized Zed was built from the ground up to support
| collaborative programming. I liked it already, and I like it even
| more now.
| phito wrote:
| I was very surprised to find a "forum" integrated in Zed when I
| first opened it. But to be honest, it is not something I ever
| felt the need for and overall I don't like having this in my text
| editor. So far it never got in my way and that's a good thing, I
| hope it stays that way :)
| siva7 wrote:
| This looks more like a collab note-taking app. Don't know about
| code since i don't code anymore inside an editor but for collab
| things who knows
| wateralien wrote:
| 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.
| drcongo wrote:
| It's just pair programming when you're doing it on code so if
| you can bear pair programming you'll be fine. Personally, I
| _hate_ it.
| wateralien wrote:
| Actively programming in pairs (or more) is also not for me.
| Reviewing work async is great IMO though.
| xpe wrote:
| Yeah, people are different, but a lot of this difference
| results from various constraints, such as cultural
| practices around collaboration or technological options.
| Many of these limitations probably shouldn't be locked in
| by our tools or norms.
|
| When learning a new way of thinking or moving (i.e. martial
| arts) people often really benefit from high-bandwidth, low-
| latency, shared-viewport-onto-reality interactions.
| Watching someone's cursor move while they talk is one way
| to get a window into their problem-solving toolkit.
| electroly wrote:
| Pair programming usually has a single "driver" on the
| keyboard to keep things controllable. Here, _everybody_ is
| driving: "dozens of cursors are concurrently editing the
| same file in real-time."
| drcongo wrote:
| That's not how they, or anyone else, uses it on code though
| - that's on their notes. This is just a feature, it's up to
| you how you use it.
| sph wrote:
| The metaphorical infinite monkeys on typewriters.
| riffraff wrote:
| a few years ago our company used Screenhero which allowed
| editing with multiple cursors while screensharing.
|
| The experience was actually quite nice for two-three people
| but we always had the "ok let me type now" flow. Multiple
| changes happening at once sounds hyper distracting.
| vablings wrote:
| The concept of sharing and taking turns has been lost on
| the software engineer here....
| a-dub wrote:
| my understanding is that this is the dynamic in modern
| college classrooms. everyone opens a big shared google doc
| for notes and they all collaboratively edit a set of notes
| in real-time.
|
| or at least that's what i've heard, no idea if they
| actually do it.
|
| it is nice to see a crdt backed editor tool for markdown
| and code though. gdocs markdown support has been lacking
| for years.
| tomComb wrote:
| True, but the option of wysiwyg for editing markdown
| would really be a great addition. Or even just for
| preview ... https://github.com/zed-
| industries/zed/issues/21717
| satvikpendem wrote:
| > _or at least that 's what i've heard, no idea if they
| actually do it._
|
| Yeah, we used to do that back when I was in college. It's
| only for certain classes and most people usually kept
| their own notes too (or instead, why write twice). Or
| some classes ban laptops so you'd write on paper anyway.
| meowface wrote:
| I think it's a fun and interesting idea for training junior
| engineers and possibly for other use cases. Suggesting
| alternatives to (perceived) bad practices the instant you see
| them could be helpful for many people, and also save a lot of
| future time for reviewers.
|
| I could also see it as a potential productivity aid. Person 1
| sees Person 2 is writing something and they don't want to be
| seen as idle, so they start working as well. This might sound
| oppressive but a lot of people who struggle with
| ADHD/procrastination/akrasia actually receive great benefit
| from that structure. Similar to that startup that forces you to
| code while screensharing with a stranger in order to push you
| to work, or people who code in cafes/libraries to be more
| productive.
|
| As long as it's not an organization _requiring_ it for senior
| engineers, I could see promise to it as an eventual common new
| paradigm.
| verdverm wrote:
| You can use remote screen control with Zoom to train up
| juniors. More often than not, you'll want to share the whole
| screen so you can show them webpages and other things that do
| not live in an IDE
| nixpulvis wrote:
| 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.
| davnicwil wrote:
| > 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.
| nixpulvis wrote:
| Problem is video is expensive and compression can get bad.
|
| I agree being able to see the pointer is important, since
| not everyone is good about moving the cursor around.
| xpe wrote:
| > Code by mass live committee. Yikes.
|
| Let's lean into the chaos and see what it might give us.
| Imagine a production application deployed directly from a non-
| version-controlled directory. Anyone on the team can edit the
| files, at any time. Insane? Probably. The disadvantages are
| easy to see.
|
| But the positives are _really_ compelling: 1. make small,
| granular testable changes; 2. use feature toggles; 3. refactor
| intensely and concurrently; 4. always work on the latest code;
| 5. use in-code documentation instead of GitHub /etc workflows;
| 6. explore continuous, incremental, hot-swappable code
| deployment.
|
| Doesn't thought of ditching all the wasted motion and ceremony
| around logging async work and _just coding_ sound glorious? I
| 'm actually not a "move fast and break things person" usually.
| But the idea of moving so fast that broken things will only
| stay broken for a tiny fraction of the time is pretty
| compelling. There is also an intensity that comes from real-
| time interactions where a team needs to reach consensus
| quickly.
|
| Feature Toggles: https://martinfowler.com/articles/feature-
| toggles.html
|
| BEAM (Erlang, Elixir) provides hot-swappable code and lots more
| tkfoss wrote:
| You just need to channel your inner Akira Nakai. There is no
| shame in being an artist. Code artisan.
| zamalek wrote:
| I have been trying to figure out how this works in concert with
| Git (or SCM in general). Is one of the developers in the session
| merely responsible for it?
| giancarlostoro wrote:
| I mean, you have the same "problem" when peer coding in person.
| Whoever is officially working on the fix will commit it. I've
| helped devs get around a hump for ages, you don't get "credit"
| for all the work you do. It's why I hate most ticketing systems
| (when management starts to ask why your tasks fell behind),
| they don't let you correctly track multiple people when they
| work together.
| sensen wrote:
| Does a `Co-authored-by:` trailer in the commit message not
| resolve this issue?
| Octoth0rpe wrote:
| 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.
| nixpulvis wrote:
| It could be easier, but it is supported AFAIK:
| https://github.com/zed-industries/zed/issues/8260#issuecomme...
| mikaylamaki wrote:
| Unfortunately, we no longer support self hosting. We're
| planning on reintroducing it once we've polished the single
| player experience a bit more :)
| Octoth0rpe wrote:
| Thanks for the update. Can't wait to hear more!
| nixpulvis wrote:
| Oh, that's unfortunate. Why not support it at all, even if
| just for people who are kinda hacking it in?
| mikaylamaki wrote:
| We've been growing and have had to scale authentication
| beyond what our original collab server could handle. Not
| many people are using collab yet, we're prioritizing non-
| collaborative features (like our recent Windows release),
| and we're planning on rebuilding all of this on top of
| DeltaDB. Fundamentally, it just fell through the cracks.
|
| Self hosting will be a vital feature for users and
| enterprises though, we're planning on revisiting it once
| we have a few more features settled :D
| nixpulvis wrote:
| Cool, thanks for the transparency and info.
|
| I'm really rooting for you guys, and your direction and
| quality is exciting to see.
| UtahDave wrote:
| Looks like development of DeltaDB has been discontinued.
|
| https://github.com/delta-db/deltadb?tab=readme-ov-
| file#-upda...
| mikaylamaki wrote:
| That is a different project :D
|
| Here's our overall pitch: https://zed.dev/blog/sequoia-
| backs-zed#introducing-deltadb-o...
| satvikpendem wrote:
| Looks great. I use some CRDTs like Loro and Automerge,
| are there any learnings or collaboration you're taking
| from them to improve DeltaDB?
|
| Also the name, I thought it was a database with CRDTs due
| to the "DB" at the end of DeltaDB, but it's a version
| control system, I thought that was somewhat misleading,
| any reason why it's named so?
| infogulch wrote:
| Oh is this based on my favoritest data structure ever:
| zed's Sum Tree?
| Aperocky wrote:
| commence feature creep
| dcchambers wrote:
| The collaboration tools built into Zed have basically existed
| since the product launched. It is one of the primary drivers
| behind the product - they wanted to build the best editor for
| remote code collaboration.
| Aperocky wrote:
| I think the most difficult question are going to be how do
| you constraint that core feature without ever wanting to add
| more to it?
|
| For instance, collaboration is a huge topic. You can have
| coding collaboration on the file, and that would be basic and
| appropriate, you can then replicate slack and you'll have
| chat rooms, which is entering creep territory, but it's
| natural! Then soon the chat room will need to link with
| issues and you can now have TODOs linked to some kanban board
| and we should be able to speak while we code on the same
| file! And this goes on and on.
|
| It's exceedingly rare that the organization found hard
| courage to specifically avoid features that looks like easy
| pickings for the purpose of avoiding them.
| max-privatevoid wrote:
| The collab editing stuff was Zed's original gimmick. The AI
| stuff is the real feature creep.
| goosejuice wrote:
| Without AI, the company would be dead in the water. You can
| very easily disable all AI features.
|
| I think Tuple is a better collab app, but far more expensive.
| TiredOfLife wrote:
| Many of these features were in Zed since first release.
|
| Also Zed was announced as a closed source comercial tool.
| otikik wrote:
| I ... don't like this one bit. I hope Slack doesn't start
| including a text editor.
| Jailbird wrote:
| There are canvases.... Some similarities if you squint. Clearly
| not for code use but for shared durable notes....
| xrd wrote:
| 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 diffs. Summaries of what happened. It isn't perfect,
| but it has been incredibly productive for me. I never got that
| from Zed's AI integration; perhaps this has been improved, but I
| was up and running with Claude in a way that I never was with
| Zed.
|
| This write-up sounds like "slack in my editor." If it is that, I
| hate it. Slack has destroyed company culture and communication.
| People, who are inherently lazy (I'm an old Perl programmer, so I
| can say that), have stopped thinking carefully and writing
| carefully, and in that void just throw the first thing in their
| head into a slack channel and think that is "collaboration" and
| "communication." It's toxic.
|
| For example, this comment rubs me the wrong way: "Staff members
| hop in, volunteer to show off a cool feature or bug fix they
| worked on, and get real-time feedback from the rest of the team."
| I don't think our human brains work well with "real time
| feedback" UNLESS we have the information presented in a way that
| gives us massive clues on what's right and what's wrong. Reading
| a wall of text is not the way. A colorized git diff, or a video,
| or an entirely new way of presenting information might make real
| time feedback possible, but I am highly skeptical a text editor
| is the way or place to do that. And, I'm an emacs user and love
| text UIs, don't get me wrong.
|
| Do I want to have "generalized one off rooms for things that
| don't fit anywhere?" I definitely don't want that. I want you AS
| THE AUTHOR to be really intentional about what's important and
| fit that into the proper channels. I need to know that
| information, but I don't want to know about, nor have the
| unspoken expectation that I SHOULD have known, about the other
| stuff. And, I want "managers" (if that still exists) to be
| carefully thinking about those channels and how the company is
| organized and push that structure down to people in the
| organization.
|
| As Zed is the office, having one off rooms instead of in person
| coffee time feels very dangerous. That's the world a lot of
| people live in, but I don't like that office.
|
| If this comment is the guiding light, then I'm worried: "We're
| building toward a future where collaboration is continuous
| conversation, not discrete commits--where every discussion, edit,
| and insight remains linked to the code as it evolves, accessible
| to both teammates and AI agents." I'm human, I have kids, I have
| other interests. A continuous conversation is impossible for me.
| I want discrete ideas, and right now, discrete commits and PRs
| are better, IMHO, than what I hear here. It's hard, but setting
| the expectation that to be successful I need to be paying
| attention to a river of information flowing by seems like a bad
| idea to me. I don't buy that Zed solves the problem of hiding the
| pieces of information that I don't need to see.
|
| Oh hey! I have an idea. Why not use AI to summarize those
| conversations into discrete pieces! </joke>
|
| I do love Zed. It is the best GUI editor out there. I know they
| will get it right. I just am skeptical about this direction and
| feel it misses the forest for the trees.
| JamesSwift wrote:
| 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.
| xrd wrote:
| 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.
| JamesSwift wrote:
| If I were still hardcore avoiding a GUI Id probably be in
| the same camp. But I moved to VSCode as my primary
| interface a long time ago, and Zed is just a better version
| of my workflow when comparing against that.
| xrd wrote:
| 100%. I also moved to VSCode years ago. Then, I got
| disillusioned by the performance, and by M$ telemetry.
| Zed is so much better in so many ways if you have to go
| with a GUI for all those reasons.
| yobert wrote:
| I agree about the bad side of slack culture, except when
| compared to how things were before slack: Horrible email
| threads, in-person meetings, phone calls, and people walking
| over to your desk to ask you stupid things they could have
| looked up themselves.
|
| Slack revolutionized this for me because I can turn it off
| anytime I want. When I want focus, I close it and it cannot
| reach me for some time. Then I pull it up and read all the
| threads while taking a poop.
|
| Having it in zed is the same: You can just log out of collab
| anytime you want! You would only use it if you _want_ to use
| it. When you do want to use it, it's incredible. Someone can
| just join your channel and work on a tricky problem with you
| and you don't even need to screen share. It's like the best of
| discord and slack available at the touch of a button. It's much
| lighter weight than slack. Slack huddles are super annoying to
| me. I want it to behave more like discord, and that's what zed
| does!
| jes5199 wrote:
| 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
| snerbles wrote:
| Often projects need a history of stable checkpoints, and source
| control is one way to provide that.
| fragmede wrote:
| Yes, but does it need all the ceremony surrounding it? If,
| every time I saved the file, the changes were analyzed and
| committed to git, and a useful commit message included, and
| commits squashed automatically and pushed and tested and
| tagged (using magic, let's say); if the system existed in the
| background, seamlessly, how would our interactions with
| source control and with other developers look?
| apsurd wrote:
| automated commit message will tell you the "what" not the
| "why".
|
| In any circle of "what makes a good commit message and why
| even do it" discussions, invariably the recommendation is
| to explain the "why" and leave out the self-evident "what".
|
| If your stance is that commit and commit messages can be
| automated away then we might as well not even have them.
|
| I don't share this view, but yeah in this world we don't
| need AI to do things that shouldn't be done in the first
| place.
| jes5199 wrote:
| increasingly, the automated systems have access to the
| original ticket or bug report, and maybe even the
| conversation while implementation is happening. They can
| record the "why"
| satvikpendem wrote:
| Use jujutsu
| mattnewton wrote:
| I feel the opposite way, that git branching and merging will
| become a bigger part of the job as more code is written by
| agents in parallel and then accepted by other agents or humans.
| jes5199 wrote:
| for now yes absolutely. but I'm already hearing rumblings
| that some people are having luck letting multiple agents edit
| the same directory simultaneously instead of putting changes
| through PR merge hell. It just needs coordinations tools, see
| https://github.com/Dicklesworthstone/mcp_agent_mail as one
| (possibly insane) prototype
|
| for example it's not out of the question that we could end up
| with tooling that does _truly_ continuous testing and
| integration, automatically finding known-good deployments
| among a continuously edited multiplayer codebase
|
| we'd have to spend a lot more energy on specifications and
| acceptance testing, rather than review, but I think that's
| inevitable - code review can't keep up with how fast code
| gets written now
| mattnewton wrote:
| Having tried a janky version of this myself with a NOTES
| directory, I am very bearish on this being a better
| workflow than just improving the ui wrapper around git
| worktrees and the isolation that provides.
|
| Codex already has a fantastic review mode, and gemini /
| claude are building tools around pr review that work no
| matter how that pr was produced, so I think this interface
| is going to get baked in to how agents work in the near
| term.
| blks wrote:
| That's a very optimistic outlook for the future.
| Romario77 wrote:
| it doesn't work quite well for complex projects that require
| integration with other teams/software.
|
| You would need to either have separate versions running at the
| same time or never do breaking changes or devise some other
| approach that makes it possible.
|
| It's not always feasible to do it this way
| jes5199 wrote:
| I think that's a tooling problem. Maybe we do end up running
| a lot more versions of things in the future. If we believe
| that code has gotten cheaper, it should be easier to do so.
| apsurd wrote:
| 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
| jes5199 wrote:
| 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
| apsurd wrote:
| 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.
| coffeebeqn wrote:
| I wonder how many nines of uptime your team is required to
| have..
| porphyra wrote:
| 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.
| Jtsummers wrote:
| Or you don't deploy unless it makes it through at least
| testing, and a build started while someone was editing the
| code would probably fail fast unless you coincidentally hit
| the button right when it's valid, but wrong, code.
| desireco42 wrote:
| As long as I don't have to use, feel free to include it. It is
| really not essential feature for editor.
|
| I run update and Collab requires you to sign in... which again,
| it is fine if you want it. I don't, so it can be dormant, icon is
| really tiny, doesn't take much space.
|
| The feature of Zed that is most annoying yet essential is
| frequent updates. Pretty much daily when I switch to Zed window,
| I can expect update and restart, which messes up my window
| layout, so this is annoyance. Getting updates and knowing you
| guys are shipping good stuff is what is essential.
|
| I think integrating terminal ai's is great move and useful.
| Sometimes I use it like that, often I use it in terminal (like
| the outside of the editor terminal) and switch to editor to
| review or update stuff. Same with git. I am old-fashioned.
| animeshjain wrote:
| I tried the collaborative features to pair program with a
| colleague a few months ago, but it was bad. It was very flaky in
| establishing a connection. In the cases we were able to establish
| a connection, the voice chat would not work. We tried to make it
| work for a couple of days, and then we gave up. Has there been
| lots of work in the past few months on the collaborative
| features?
| conradev wrote:
| 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 Hydra 1.0.1, a Rendezvous-based text editor that
| enables multiple people to contribute to a shared document. (Adam
| and about ten other attendees at MacHack used Hydra to take notes
| during this year's Hack Contest.)
|
| It seems like the "unlock" here that makes it different this time
| is organization-wide sharing.
|
| https://en.wikipedia.org/wiki/SubEthaEdit
|
| https://tidbits.com/2003/06/30/apple-announces-design-awards...
| sandbags wrote:
| I'd forgotten all about it but SubEthaEdit was such an amazing
| tech when we were using to collaborate internationally back in
| about '04. It went off my radar but I am glad to see its still
| available as a free app.
| Aurornis wrote:
| 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 takes a lot more
| developer effort now than it did in the 2000s.
| leetrout wrote:
| > 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.
| xpe wrote:
| > but it's notable that shipping next-gen editor software
| takes a lot more developer effort now than it did in the
| 2000s.
|
| Yes, the scope increase is vast, due to more languages, more
| tooling, more features, higher expectations, and more
| competition.
| mikaylamaki wrote:
| 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
| domenkozar wrote:
| You guys need to figure out how to create Slack shared channels
| in Zed and we're all switching until they won't be needed
| anymore.
| alberth wrote:
| Can you share more on this.
|
| While I do _not_ work at Zed, I 'm curious to hear more about
| this use case for my own company needs.
| leovander wrote:
| Your company has a user pool, you sign a BAA or start working
| with a partner company that has their user pool. Instead of
| creating slack accounts in both you can share external slack
| rooms that only people that are invited in/from their
| respective orgs can join without having to co-mingle employee
| user pools.
| satvikpendem wrote:
| But why would external partners want to look at your code?
| I guess if you're also integrating with them? But generally
| you just give them repo access instead. For Slack, it's
| different as messaging is a core feature to collaborate
| between different people in different companies, but
| looking at code is a very specific use case.
| aanet wrote:
| /offtopic
|
| Is it just my vision, or are websites getting super low contrast
| these days, esp the text-heavy ones?
| bityard wrote:
| I'd say it's medium gray on white, which is not too bad in my
| subjective opinion. I have seen far worse. Light gray on white
| was "trendy" for a while and dark gray or dark green on black
| has always been popular among the edgy crowd.
| gpm wrote:
| I feel like that's been a trend for the past decade at this
| point. I don't think this one is particularly egregious but it
| ain't great either.
|
| Could be your monitor as well.
| duderific wrote:
| Also the typeface, kerning and line heights are a bit -
| unconventional, which doesn't help the readability
| porphyra wrote:
| Haha it's like Google Wave!
| tracker1 wrote:
| These are definitely some interesting features, though not sure
| I'm in any position to take advantage of them at all.
|
| The multi-user editing is kind of cool... there's an ANSI art
| tool (PabloDraw) that you can run a host session so multiple
| artists can create text art, and I thought back when I first saw
| it, that it might be cool to be able for multiple editors to work
| on a project. I've used some of the collab stuff with VS Code,
| but haven't done enough to even begin to compare.
|
| Not to mention that in a lot of workplaces, self-hosting or
| otherwise layers of bureaucracy stand in the way.
| mariusor wrote:
| Is this the new Zawinski's Law? Instead of extending to read
| email, Zed extends to enable chat and voice-video. :)
| antoniojtorres wrote:
| I've been using "The Notioning" for the last few years to refer
| to the convergence of tools like slack adding notion like
| features, clickup adding notion and slack type features, and so
| on. There seems to be a stable set of features that retains
| teams in an org
| verdverm wrote:
| Perhaps we can call it the "Hashimoto Valley", analogous to the
| Uncanny Valley, but for DX
| satvikpendem wrote:
| What does this have to do with Hashimoto?
| verdverm wrote:
| HCL / TF DX and my missassociation of Zed / Hashimoto (see
| where I was corrected elsewhere in these comments)
| nixpulvis wrote:
| I would love to see collab servers take the same path as LSPs in
| being standarized and integrated across various editors and IDEs.
| I would love to work more closely with my VSCode peers, for
| example. Of course some features may be outside the standard and
| only supported with likewise editors, e.g. voice chat perhaps,
| but having shared cursors and a text chat would be a good start.
| bluehatbrit wrote:
| This is what I'd like to see as well. These collaboration tools
| are really good, but I barely use them because they always
| assume that you and your team are using the same editor. Most
| of the time that's just not the case, so I've used them a
| handful of times but beyond that there's little opportunity.
|
| It's probably not an issue the Zed team will experience as
| they're all naturally using their own editor. Hopefully it's on
| their radar though.
| satvikpendem wrote:
| > _because they always assume that you and your team are
| using the same editor._
|
| Network effects are probably a strength for a company, not a
| drawback (which it is for the user of course). Even VSCode
| has some notion of network effects, such as their proprietary
| extension store.
| the__alchemist wrote:
| Here is where I've settled on for Zed. I initially thought it
| might be a Sublime replacement for one-off files, but it seems
| it's geared towards projects. It's not as powerful as Jetbrains
| (RustRover, PyCharm etc), but is _much_ faster. So here 's how
| I'm using Zed: - On my Tablet, which is too slow
| for Jetbrains IDEs to run smoothly - On certain projects I
| have which choke Jetbrains IDEs. (Due to macro use maybe?)
|
| I think its' a much nicer experience than VsCode, which I
| admittedly haven't figured out to run in a project-oriented way.
|
| I'm also trying their GPUI library, but am in the early stages,
| so can't really comment on how it compares to EGUI.
| nixpulvis wrote:
| 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 an
| SSH connection once and then doing everything from there.
| the__alchemist wrote:
| 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!
| nixpulvis wrote:
| 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.
| xyzzy_plugh wrote:
| > 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.
|
| I'm sorry... what?? I still use vim as I haven't found a
| reason to jump to neovim, but you're telling me external
| commands don't work properly? That's wild.
| nixpulvis wrote:
| They "work"... but instead of switching back from the alt
| screen and giving you your terminal back, they open a
| gimped little window within vim which makes it hard to
| navigate, copy, and search for things in the output.
| kwanbix wrote:
| Why would you use a tablet for this type of work? Honest
| question.
| the__alchemist wrote:
| Surface tablet, so it's like a laptop. I can kick the
| keyboard off when I'm reading stuff, to allow room for food
| and drinks. And I do drawing/notes with the pen.
|
| Another way of stating this: It's a general purpose portable
| computer; not specialized coding PC.
| sayrer wrote:
| Haha: Can't find a good Windows laptop.
|
| It's true, most of them are bad. Galaxy Book5 Pro or Microsoft
| Surface are OK.
| thewebguyd wrote:
| Ever since Apple Silicon macs came out, it's been a real
| struggle. Almost 6 years later and there is still nothing on
| the market that:
|
| * Has the same level of performance
|
| * With the same or better battery life
|
| * With the same quality of screen
|
| * With the same quality of speakers and touchpad
|
| * Runs as quiet or as cool
|
| as the Apple Silicon macbooks. If you add in "needs to be able
| to run Linux" your choices go down from maybe 1 or 2 to 0.
|
| They all have some sort of compromise. Either the speakers,
| screen, keyboard, touchpad, build quality, battery life, or
| thermals.
|
| I have a Surface Laptop 7 with the Snapdragon X Elite, and it's
| pretty close. Checks the boxes for Screen, build quality, and
| touchpad. Loses out on speakers and battery life, and the fans
| need to run a lot more than my M4 Pro MBP does. It also loses
| on performance, and it doesn't run Linux. Windows on Arm also
| still has a lot of little quirks and bugs that start to become
| daily annoyances.
|
| It's incredibly frustrating. I want, essentially, my 14" M4
| MacBook Pro, but in a Linux laptop, and there's no OEM out
| there that's fulfilling that need without compromises.
|
| Apple keeps pulling ahead in silicon and every other laptop OEM
| is just being left in the dust, shrugging their shoulders, and
| putting out the same old 1200p 16:9 plastic garbage they have
| always been putting out.
| _se wrote:
| Don't tell the Posthog guys about this. Far too much
| collaboration going on here!!!
| ufko_org wrote:
| Just another fence for monkeys :)
| tacone wrote:
| Don't want to sound negative, yet when I read "it's in our DNA",
| I immediately lose interest.
| Redster wrote:
| It would have been good to include a link to the collaboration
| docs https://zed.dev/docs/collaboration in the article. There
| were a lot of links in that article and a lot of assumptions that
| I knew how things worked. And I daily drive and like Zed, but I
| had so many questions.
| blks wrote:
| I lost all faith and interest in Zed after they introduced AI
| features.
| bigyabai wrote:
| That's alright, there's always Sublime Text.
| maratc wrote:
| Or TextMate -- that Sublime was, let's say, "inspired by."
| acdyer824 wrote:
| you dropped this king
| frankfrank13 wrote:
| Why? Its still incredibly plug and play, by default you don't
| even see it
| jazzyjackson wrote:
| The AI features work well but to each their own
| richardhenry wrote:
| I feel the opposite way, but fwiw you can turn off all AI
| features in Zed by adding `"disable_ai": true` to your
| settings.json.
| robinhood wrote:
| Technically really impressive. In practice, completely
| unpractical in any medium to large organization. And although I
| adore Zed's speed and reliability, I still don't understand why
| we need these features at all.
| jazzyjackson wrote:
| Because Zed is not somebody's side project, it's a business
| looking for ways to pay everybody's salary
|
| > Collaboration as it stands today is considered alpha, and for
| the time being, is free for all to use! Peruse the source code.
| ModernMech wrote:
| Because "maximum editor" was achieved with Visual Studio Code
| (which is why all these new editors _look and feel_ like VSC),
| the same way "maximum toothbrush" was achieved with the
| electric toothbrush. But the toothbrush industry had to keep
| going, so now we have a $400 bluetooth connected toothbrush-as-
| a-service that monitors your brushing habits to optimize teeth
| cleanliness, with brush heads that cost more than 5 regular
| toothbrushes.
|
| Zed and the current crop of AI editors (including VSC itself)
| are that toothbrush.
| Iwan-Zotow wrote:
| Zed's dead, baby, Zed's dead
| frankfrank13 wrote:
| Very cool idea, and helps promote owning your own data, and it
| being highly interoperable (plain text!)
|
| I do wonder if we need a term for shoe-horned dogfooding though.
| Like sure, you can do this. You could do this in Figma! Or in
| Notion! Or in LEETCODE if you wanted to.
|
| At least with Zed though, its plain text. If you find another way
| to collab realtime on plain text, you're not bound to 1 vendor.
| verdverm wrote:
| I really really don't want comms or multiplayer tools in my IDE.
|
| Don't bring the attention economy to my cave of solitude, it's
| where I go to escape all that noise
| pprotas wrote:
| I removed the collaboration panel from my bottom bar and don't
| have to deal with it at all. Can recommend
| verdverm wrote:
| I stay away from anything Hashimoto is making after my
| experiences with TF & HCL, or at least the bar is much higher
| / projects get a lot more scrutiny
| hrimfaxi wrote:
| What does Mitchell Hashimoto have to do with Zed beyond a
| guest blog post?
| verdverm wrote:
| My understanding is that he is involved in the
| development of Zed
|
| I find Zed's feature choices to be really poor, and then
| I probably made a poor association based on his talking
| about zed
| smj-edison wrote:
| I know he's working on ghostty, but I've never heard
| anything about him working on Zed, was that what you were
| thinking of?
| RaoulP wrote:
| Hashimoto writes Ghostty in the Zig programming language.
| There might be a mixup here between Zig and Zed.
| pprotas wrote:
| Yea you're thinking of Ghostty, this topic is about Zed,
| which is not related. In fact Zed uses Alacritty for their
| terminal, I wish it was Ghostty!
| satvikpendem wrote:
| Zed is sticking to all Rust, it appears, so Ghostty
| wouldn't work. Also Ghostty has a lot more UI features
| itself like tabs etc so I don't think it's as easy to
| integrate in an editor which also has its own UI, so
| Alacritty being mainly TUI driven makes more sense.
| echelon wrote:
| This feels like a huge distraction from building an IDE.
|
| A monnumentous yak shave.
|
| I've never used or cared for multiplayer in VSCode or
| JetBrains. It's silly.
|
| I've never been the pair programmer type. The only time I've
| needed to share an IDE is during a SEV or ridiculously
| complicated systems bug, and that's 1% of the time.
| agrippanux wrote:
| Their multiple rounds of VC funding are predicated on their
| vision of collaboration so they gotta make a go at it.
| aeturnum wrote:
| It's not something I am _excited_ about, but it is something I
| want my IDE to _do well_ if I must engage with it. Other remote
| pair programming experiences are even worse and I appreciate
| Zed 's capability in the area even if it's not what I prefer.
|
| A lot of my IDE choices are about extensibility and flexibility
| more than perfection for my preferred coding approach. After
| all, until I only work for myself I need to be ready to
| accommodate the needs of others as part of my job.
| sunnyps wrote:
| > Despite attempts to make Atom--an Electron application--more
| responsive, it never reached the performance standards the team
| yearned for.
|
| This feels like an attempt at deflecting blame. VSCode is another
| Electron application that ended up having better performance than
| Atom. There's another Electron adjacent application that has good
| performance _, the one you 're probably using right now to read
| this page.
|
| _ Depending on page content of course
| kriops wrote:
| What are you saying here? It is true that VS Code is less bad
| in terms of responsiveness in comparison to Atom. Zed, however,
| is written in Rust (i.e., not Electron), and I would guess it
| is _at least_ an order of magnitude more responsive than VS
| Code across every possible scenario.
|
| Web technologies are an unrivaled technological marvel for what
| they are, but it is disingenuous to imply they represent
| anything near the peak of what we are capable of in the context
| of performance.
| IshKebab wrote:
| It depends. It definitely opens faster and the general UI
| seems a bit faster, but open a largish file (a few MB) and
| VSCode will easily out-perform Zed because it doesn't have
| that fancy CDRT thing.
|
| In my experience VSCode is plenty fast. Use it with no
| extensions and you will have zero problems with performance
| (though memory use isn't great). The real problems come when
| you have extensions, especially because it's often impossible
| to attribute performance issues to them because they can
| often do a lot of work all in the same "extension host"
| process.
| verdverm wrote:
| Why is Zed using a CRDT when I open a source file to edit
| code? Are they using it for more than their multiplayer
| stuff? (agentic stuff?)
| satvikpendem wrote:
| Based on this comment [0], they're building DeltaDB as a
| version control system which uses a CRDT, so I assume
| even in single player mode, the file will instantiate its
| own CRDT for fine grained tracking of changes.
|
| [0]
| https://news.ycombinator.com/item?id=45916196#45919739
| cantalopes wrote:
| If you use vscode on a platform with limited resources you
| will see that vscode is absolutely NOT fastand zed
| outperforms vscose long way. Extensions or not. And
| electron is a pleague that needs to pass from this world
| TiredOfLife wrote:
| > VSCode is another Electron application that ended up having
| better performance than Atom
|
| Atom was kinda like emacs. Extensions could do almost anything.
| VS Code has a limited api that extensions can use
| travisgriggs wrote:
| I like Zed. I pay for pro. I like the integrated agent stuff
| (though my usage model has changed a bit after 5 months of use).
|
| I'm happy that others can type in each others' space, but this
| post reveals a tension here. They are building a tool for
| building the tool, and their own team. I think that's cool, but
| at a 2-3 person shop heavy polyglotted across 4 OSes and 5+
| programming languages, this is not what I really need.
|
| What I'm looking for is a snappy tool (check) that lets me
| explore, understand, modify code at a next level (marginal). And
| I want it to not only be snappy by virtue of execution
| efficiency, but cognitive load. I want the less-is-more
| experience. I don't need it to do Swift, Kotlin, or Python,
| because there are bespoke IDEs for each of those that focus on
| the environments where I deploy them best. What I mostly want
| from Zed is the ability to see the outline panel at the same time
| as the directory panel, and to separate the search outline from
| the file structure outline. I spent too much time toggling views
| in Zed.
| olejorgenb wrote:
| > What I mostly want from Zed is the ability to see the outline
| panel at the same time as the directory panel
|
| You can do this now by moving one of them to the right dock
| (right-click the toggle-button)
| travisgriggs wrote:
| And then toggle between that and the AI agent? Zed is a
| workbench that lets you put two, and only two, tools on your
| "workbench" to either side of your text workspace. I want to
| put more tools on my benchtop.
| olejorgenb wrote:
| > And then toggle between that and the AI agent?
|
| Yes
|
| - Do you want to split a dock vertically?
|
| - Do you want to open the panels inside an editor split?
|
| - Do you want to detach the panels as separate windows?
| (https://github.com/zed-industries/zed/issues/17618)
| BinaryPie wrote:
| I generally like what Zed is trying to become. However, all of
| these features and blog posts are frustraing when they struggle
| to keep basic editor features stable. Edit a file outside of the
| editor? It's not going to show up in the project pane or the git
| diff. Need to work inside a container because it's 2025 and we
| don't need to clutter our local machine with 100s of dependencies
| and env managers... well now all the AI stuff is broken. ACP
| sounds cool until you realize every single CLI in existence works
| better.
|
| My wish is that Zed gets the core working correctly 100% of the
| time before moving on to expanding feature sets. For now I'm back
| in NeoVIM because it always works the first time....
|
| https://github.com/zed-industries/zed/issues/38109
|
| Hopefully soon I can give it another shot at full time usage.
| lvl155 wrote:
| I agree with you 100%. If basic functionalities are not
| airtight, there's no way I am going to deal with growing pains
| just because they want to get paid on AI fluffs. Contrast this
| with something like Ghostty.
| mystifyingpoi wrote:
| How does Neovim handle outside changes then? Or is there a
| plugin to make it work? AFAIK it doesn't reload any bufferes
| when files change. IntelliJ is the only other one I know that
| does it transparently.
| vmiklos wrote:
| Plain vim asks what to do by default. A single 'l' does a
| reload.
| BinaryPie wrote:
| In vanilla neovim you can use autoread... this does depend on
| a focus event like entering and leaving the pane or switching
| buffers. However, for my workflow which is "go to a different
| terminal pane and do some things then switch back" as soon as
| I focus the buffer it updates.
|
| Where as with Zed it'll just keep showing the old content and
| in fact closing and opening file wont even change what it
| shows in Zed. It's really really annoying. I have to exit zed
| and open it again. This means if you are working with AI
| agents you end up having to do this often.
| rorychatt wrote:
| Very strange, this has always worked for me with Zed - both
| with local and remote ssh sessions.
|
| I use `"autosave": "on_focus_change"` which may be keeping
| my buffer in sync with the file contents as I switch
| between terminal and zed.
| lawn wrote:
| You can configure Neovim to either auto reload or to ask you
| whenever a file is changed. (Can't remember which one is the
| default, probably to ask.)
| mystifyingpoi wrote:
| Thanks, just found something about that.
| OkayPhysicist wrote:
| I'm ~80% sure auto-reload is on by default, and 100% sure
| that it's on in a fresh LazyVim install.
| qiine wrote:
| vim.o.autoread (default on) When a file has been detected
| to have been changed outside of Vim and it has not been
| changed inside of Vim, automatically read it again.
| yobert wrote:
| My experience has been so different. Zed seems to always do the
| right thing for me when I concurrently edit files with other
| tools. Not doubting your experience or anything, but you must
| have a very different environment than me. Zed has been
| absolutely rock solid for the past year on my computer.
| jchw wrote:
| I am _not_ getting tons of issues with Zed going out of sync
| all the time. I wonder if the issue is it silently having
| issues watching the filesystem due to open fd limits.
|
| I've noticed that not only does it sync but it even will
| recognize if I rename the folder a workspace is in.
|
| But then, I've run into a couple of strange issues that tell me
| there is more polish needed:
|
| - Sometimes upon using LSP refactor, it seems like if a bunch
| of files get renamed, the open buffers will get screwed up
| somehow. Like, I'll hit save and it will write to the old
| filename! It's not actually a huge problem, as I can close the
| buffers, delete whatever excess files I accidentally create,
| and re-open them without error, but it is confusing as hell.
|
| - I have indeed had issues with the file view not always
| updating when files are added externally, however it is not
| constantly. I usually just reload workspace when this happens.
| It is a minor frustration, but I had many minor recurring
| frustrations with both VS Code and Neovim before too, so I
| don't consider it a deal breaker.
| iknowstuff wrote:
| Oh yeah I've noticed both the desync and AI not working via
| ssh.
|
| Also buggy git support, I selected a few things but it
| committed everything and made me think I lost it all.
|
| But I love Zed when it works. Literally 5h more M4 battery life
| vs Cursor.
| gryn wrote:
| yup, my pet peeve is there is no way to disable line wrap. the
| setting that exist doesn't work and there's no way to actually
| disable it instead of just increasing the max characters (with
| set hard limit in the source code).
|
| have a big docs or log,data file where you don't care for the
| rest of the line ? well too bad better have a spare editor.
|
| this feel to me like it should should be a number #1 priority.
| "an editor need to nail the editing part".
|
| https://github.com/zed-industries/zed/discussions/26344
|
| on the positive side I do like that you can in-place edit the
| result of global search.
| rsolva wrote:
| Yeah, I have been fighting Zed to get agents to use podman on
| my host, but Flatpak is sandboxed and makes it almost
| impossible. The ideal solution would be that Zed could use
| podman or docker to spin up a container where agents could run
| free!
| maxbrunsfeld wrote:
| Agreed, we should support this!
| tecoholic wrote:
| With the AI stuff, it feels like they invested a bit
| prematurely. When the Agentic editing demo came out (6 months,
| 10 months ago? It's a blur), it felt right. Accepting and
| reviewing edits, live tracking ..etc., felt like pair
| programming. The ACP addition felt like a natural evolution .
|
| With the continuous improvement in CLI tools and people's
| experience with them, it feels like doing a live review or
| edit-by-edit approvals all feel like a drag. I personally have
| come to avoid using the IDE/Editor. I just kick up Claude code
| - plan mode, auto-accept edits. Once the session is done,
| switch to the editor and make necessary adjustments. I suspect
| people with Max subscription and "dangerously-skip-permissions"
| ...etc won't even care if an editor has AI integration or not.
| girvo wrote:
| The only editor integration I think is semi useful is wiring
| it into Diagnostics/Problems data that the editor has from
| extensions. Speeds up the agents flow quite a bit when it
| leans on that to check its work vs always executing (say)
| "eslint" directly.
|
| But that can be done easily enough with an MCP extension for
| your editor/IDE of choice
| maxbrunsfeld wrote:
| Curious about the failure to detect FS changes made outside of
| Zed. Are you on Linux?
| rsolva wrote:
| I have observed this too, mostly for content that is changed
| in a symlinked directory, but also generally. I'm on Fedora
| Silverblue running Zed Preview as a Flatpak. It works great
| in most other ways though, snappy and beautiful, but the
| sandboxed environment provides some additional challenges.
| 85392_school wrote:
| The thing about "basic" here is that it's subjective. It could
| be that these issues only happen on your machine or that the
| staff (or even most people) don't need what you're asking for.
| Of course they should try to fix them anyway, but their backlog
| is enormous.
| recroad wrote:
| Agreed. I hear way too much about Zed considering the editor
| doesn't allow a window to be popped onto a second monitor.
| zie wrote:
| On MacOS 10.15, I have 2 monitors plus the built in on a
| macbook pro, and I have Zed windows on all 3 of them all the
| time.
| girvo wrote:
| I know this is silly but the biggest thing that's driving me
| away from it is how god awfully blurry it looks on my 1440p
| screen :/
| phcreery wrote:
| This is also a big issue for me and has one of the largets
| issues for a while. [1] I wish there was font hinting to the
| like of windows font rendering.
|
| [1] https://github.com/zed-industries/zed/issues/7992
| chrisweekly wrote:
| That's not silly! Great UX is table stakes.
| NewsaHackO wrote:
| I don't have this problem, but issues like this are always a
| huge barrier, especially when you want users from a polished
| code editor like VSCode. Personally, I use it because
| VSCodium does not support the default Python LSP on my Linux
| box. I like it, but there are definitely areas that seem
| rough around the edges. My biggest issue is the size of the
| font and icons. I use a 4K screen, and while the font is
| readable, the icons are so tiny that I can barely see them.
| Since it is a new system, I don't just know where they are
| like I would if it were VSCode.
| jokethrowaway wrote:
| Try the latest version, it should be better
|
| Personally, I never registered that as a problem, but I can
| see the delta in screenshots between versions.
| tharne wrote:
| > I know this is silly but the biggest thing that's driving
| me away from it is how god awfully blurry it looks on my
| 1440p screen :/
|
| Not silly at all. User experience is important. If you're
| going to spend as much time in a tool as most programmers do
| in their editors, it should look and feel nice.
| easygenes wrote:
| It says they're targeting Spring 2026 for their 1.0 release, so
| I'll treat as beta and put a calendar entry in for April 2026
| to check back in on it.
| bitbasher wrote:
| Maybe I'm old, jaded, stubborn and paranoid, but something about
| a coding editor that is controlled by a company is off-putting to
| me. It's even more off-putting when you add Zoom, Slack and
| everything else into said editor.
| aduffy wrote:
| ...you're free to use other editors? People like Zed. They like
| IntelliJ. They like VSCode. If you have an aesthetic preference
| against _all_ professionally maintained IDEs, I think you're in
| the minority.
| bitbasher wrote:
| ...doesn't mean the majority is right :)
| cipehr wrote:
| ...doesn't mean there is a right or wrong either :)
| malkia wrote:
| Please work on decreasing the binary size - it's whopping 400mb!
| insane_dreamer wrote:
| Looks very cool, and of course it's nice to basically have Slack
| inside of Zed.
|
| But personally, what I want in a Code Editor / IDE, is to be the
| very best experience at writing code and working with code
| projects. That is what will save me time and make the coding
| experience better.
|
| Collaborative features are nice but not essential since there are
| other tools out there. It's not likely to move a team away from
| Slack (though if it's self-hosted, it stands a chance).
|
| I'm not yet at the point where I can rely solely on Zed for
| python coding. I mostly use Zed because I like new initiatives,
| especially open source ones, and it's fast and responsive. But
| PyCharm is still better for python development at this point,
| with its one black mark being endless indexing on large codebases
| / dependencies, and I find myself falling back to it regularly. I
| would argue that the priority should be to achieve parity as a
| _code editor / IDE_, and then we can talk about other shiny new
| features.
| submeta wrote:
| Whenever a product tries to be too many things, it dilutes the
| core USP. Try to be an excellent code editor. Add extensibility.
| Done.
|
| I get it, you are VC funded, investors want to turn this into a
| multi billion dollar unicorn.
|
| Do not focus on investors, but developers.
| woile wrote:
| To me it feels like 2 different set of products, what they are
| showcasing here seems very similar to slack/teams.
|
| Of course, it would be awesome to have a faster and open source
| slack, and if I can take notes on the same style as my editor
| great. So I guess, it would be nice to be able to embed zed in
| another product.
|
| I think this would be appealing for a company that it's core
| product is code, like zed, but I do wonder if other companies
| even need this functionality.
| stickfigure wrote:
| Looks a lot like Google Wave. This is interesting for some things
| but I don't think coding is it, for the same reason that
| IntelliJ's CodeWithMe doesn't work for pair programming. And
| apparently one of the guys is a former Pivot, so it's a little
| surprising.
|
| Pair programming is Two People One Cursor. A critical aspect of
| it is you're both looking at the same lines of code and working
| on the same problem and following each other's thought processes.
|
| CodeWithMe (and it seems Zed) is Same Codebase, Same Day. There's
| no shared focus. You edit stuff, I edit stuff, maybe there's
| overlap. But this isn't much different from doing separate git
| commits.
|
| So far the only remote pairing tool I've found that works
| competently is pop.com.
| spockz wrote:
| Pair programming so often degrades into one pilot and one
| person just sitting there trying to catch mistakes. When those
| mistakes are caught they are mentioned taking the first persons
| attention away and breaking flow.
|
| In contrast how I like to work, with similar level people, is
| to work at the same feature in the same codebase at the same
| time. We either sit next to eachother, or have a remote call,
| where we continuously talk through what we want to achieve.
| Sometimes this results in one person writing ahead (code, docs,
| doesn't matter) and the second sweeping behind it and cleaning
| it up. Two cursors, one source. IntelliJ even manages to keep
| authors correctly in git.
|
| The other mechanism is where we work on different parts of the
| code base at the same time. Either main code and tests, or
| split across interfaces and implementations. Because this
| happens on the same machine the iterations are way faster as
| they are local and incremental.
|
| This basically saves the whole dance of creating branches,
| pulling/pushing, the fixing typos etc.
| iparaskev wrote:
| With zed you can also share your screen in the editor which
| makes it a bit better, but still you can't take control of the
| other machine.
|
| IMO if you only care about coding doing it in the editor is the
| best approach, you get zero latency and have all the context
| that you need (most of the times). But if you want to do more,
| like opening the browser for whatever reason, or teaching how
| to use a specific cli, etc, then taking control works better.
|
| If you liked pop you might like gethopp.app, which is an OSS
| pair programming app (full disclosure I am the co-maintainer).
| Unfortunately because we have chosen tauri for the frontend we
| can only support macos and windows, but I am working on a
| solution for Linux too.
| railing wrote:
| Any plans to leverage 3D at all in the interface?
|
| was floored by the "explode all layers in the user interface and
| simulate a 3D camera rotating around them" graphic when i first
| saw it !
|
| 3D is always difficult to get right, but felt it had some really
| cute possibilities,
|
| any way to open this up so devs can try things out?? < 3
| seanssel wrote:
| > was floored by the "explode all layers in the user interface
| and simulate a 3D camera rotating around them" graphic when i
| first saw it !
|
| What is this in reference to?
| railing wrote:
| https://zed.dev/blog/videogame !
| seanssel wrote:
| thanks!
| dzonga wrote:
| i'm now guessing the software engineering universe is becoming
| like the lawyer ones
|
| 1. big corporate shops / vc funded ones - many tens of
| programmers working on features (this is where zed collab
| features might be needed) 2. bespoke high productive small teams
| - less than 5 product programmers in a company e.g basecamp -
| these would be your bespoke law firms 3. the indies (injury
| lawyers) -> 1 - 3 programmers chunning out products at scale or
| eating of one product + maybe with help of A.I
|
| for 2 & 3 - a lot of stuff being shilled is not needed. a legal
| pad + some notes that can be posted via a google doc is all
| that's needed. Jira isn't needed too
| alberth wrote:
| I love Zed's minimal design language ... clean, restrained
| colors, low visual noise.
|
| The screenshot below surprised me:
|
| https://zed.dev/img/post/zed-is-our-office/this-week.webp
|
| All the colorful avatars and the busy side/top panels feel out of
| character with the usual Zed aesthetics.
| arjie wrote:
| I use Zed instead of my normal text editor because it opens
| instantaneously. But I don't write code in it, and still use my
| IntelliJ + IdeaVim with Claude Code and Codex in a separate
| terminal in Ghostty.
|
| But Zed is an insanely fast text editor to open text files in.
| Just double click and it's on the screen. Love that. Maybe over
| time I'll do more in it.
| nrhrjrjrjtntbt wrote:
| If that is all you need there has always been Vim and Nano.
| arjie wrote:
| I do use (and am in the Backers.md of) neovim. But the GUI
| versions open much more slowly than Zed. Zed is near
| instantaneous. I do often edit text in neovim by opening a
| terminal window and doing things, but the experience of
| browsing a large log file and filtering through it is much
| nicer in a GUI text editor, so if I ever double-click or open
| a JSON file I want that to happen instantly.
|
| I can't stand Nano. I find it impossible to use because my
| brain is strongly vim-bound.
| hk1337 wrote:
| From reading some of the comments, I'm not sure which is worse,
| Zed Shaw or Zed the code editor
| aadishv wrote:
| There is a lot of complaints about Zed in the comments here. I
| don't think that they are "hate", per se; they all definitely
| care about Zed and want it to succeed.
|
| I daily drive Zed for work across several languages and I love
| it. I use a lot of its features, like the git interface, agentic
| editing, etc. I might even consider paying for Pro in the future
| if I want unlimited edit predictions.
|
| However, all of these complaints are fully justified. I think Zed
| is a massive undertaking, only one that a VC-backed company has
| the capital to do. iirc, it requires 70k lines of Rust just for
| the cloud part [1]. I cannot fathom the amount of fundamental
| infrastructure they have to get the editor functional at all.
| That doesn't excuse all of the papercuts in Zed though.
|
| If I were Zed I would do the following:
|
| 1. stop all work on future features, like DeltaDB etc. They all
| seem extremely cool but they won't meaningfully contribute to
| increasing Zed adoption or fixing its issues.
|
| 2. remove all agentic editing features. if Zed tries to
| simultaneously become the world's best agentic editor and a good
| general-purpose text editor, it will fail at both. Keep around
| ACP so users can still use other agents, but remove all of Zed's
| built in agent stuff.
|
| 3. fix literally every papercut. Triage every single issue and go
| through every PR, even if it will take half a year to do so.
| People won't switch to Zed until it's perfect, and the existence
| of this many issues means it's not perfect enough.
|
| 4. make extensions actually good. Every programming language,
| library, etc. has it's own ecosystem, and many such ecosystems
| mainly rely on VSCode extensions for advanced features. Zed needs
| to be extremely extensible like VSCode is; obviously its
| architecture makes this slightly harder, as it's nontrivial, for
| example, for extensions to render their own GUI, but there are a
| lot of low(er)-hanging fruit for extensions that need to get
| solved. People will only switch to Zed if they can get a similar
| breadth of ecosystems.
|
| Of course, this won't happen, and given that none of these will
| really make them money, Zed has no incentive to focus on these,
| especially given the amount of time they would need to do this.
| But I think that if Zed can't nail the core experience, it won't
| get anywhere.
|
| [1] https://maxdeviant.com/posts/2025/head-in-the-zed-cloud/
| another_twist wrote:
| I understand interacting with other engineers right in the editor
| but I dont get why so many collab tools need to be bolted on to
| what is basically a text editor. This will only fragment
| communications since its not just engineers that work in any
| company. Meaning you'll now have communication spread out in
| Slack and Zed making collaboration difficult, not easy.
|
| I dont honestly dont get the allure of pair programming. My pair
| programs are the unit tests which I run as often as I can and
| limit discussions to Gitlab/Slack. I have worked ag FAANGs and
| large companies and never once pair programmed anything.
|
| I honestly cannot think of a single software or process problem
| that requires real time collab in the editor. Having said that it
| is a cool feature and I quite like Zed as an editor.
| piker wrote:
| A cynical take is that pair programming in the IDE implies
| network effects and custom protocols. Just the types of moats
| necessary to get VC backing.
| eddythompson80 wrote:
| My understanding was always that this is a way to monetize a
| text editor. How else do you monetize dev tools? Developers are
| used to very high quality free tools. You're either one of the
| few old guards (like JetBrains, Microsoft or maybe Oracle) that
| can sell IDEs and other dev tools because 25 years ago open
| source dev tools were far from beginner friendly.
|
| But how do you monetize a programming language, a text editor,
| a build system, a terminal emulator, etc in 2025? The examples
| are deno, bun, mojo, nextjs, zed, earthly, warp, etc. all know
| they can't monetize the actual tool. You monetize services that
| you build around the tool. Like a cloud/workers/deployment
| (basically compute), or a sharing service or an AI service,
| etc. once you have critical mass on your platform, you can find
| other easy services to offer. Like if Zed has a critical mass
| of users, maybe the offer "in editor chat". A small startup
| with just 3 devs working together can replace slack with zed.
| Maybe they offer an uptime check service. Why not? Maybe a file
| sharing service. Maybe a small wiki service, etc. all things
| that have million other solutions. But if you have critical
| mass, someone will pay for those things.
| noobly wrote:
| I listened to the founders explain that the current process of
| syncing up to review or question code is very multi-step and
| sort of inefficient almost adversarial at a high level. A slack
| mention, Github discussion, screen share, etc it all ends up
| being kind of disorganized and painful versus just being able
| to edit the document collaboratively and directly, perhaps
| leaving some metadata tagged at certain locations (e.g, notes
| from a conversation about the code).
|
| It's not like the editor prevents one from still using slack
| and other external tools, either. I guess I just see the value
| in in-editor integration to handle that stuff more smoothly, at
| least for those using the same editor.. I can see myself really
| appreciating the feature if there's a part of the codebase that
| consistently trips people up or is under active discussion.
| TiredOfLife wrote:
| > why so many collab tools need to be bolted on to what is
| basically a text editor. This will only fragment communications
| since its not just engineers that work in any company
|
| Once they finish their collab platform they can make it
| standalone. The current version in Zed seems to be isolated
| very good.
| cpeth wrote:
| Zed looks really cool and I would love to give it a try, but I am
| just too beholden to devcontainers. I know there are workarounds
| to use them with Zed but with many extra steps compared to VS
| Code and it's forks. I can't go back to not having a totally
| integrated container per repo.
| cantalopes wrote:
| It's truly showing that the zed team is chauvinistic by
| dismissing different encodings not being supported and focusing
| on other things. "It wurks in merica", it gut i guess
| jokethrowaway wrote:
| This is insanely cool but it would be hard for non dev people to
| join the meetings and there is always an annoying "camera on"
| policy.
|
| Moreover, this would be competing with Google Meet, Teams, Slack,
| Gather - way too much tech for collaboration
|
| And I wish we were more async-first and less forced to deal with
| humans, especially over the network.
| tharne wrote:
| It's nice to see Zed's collaboration features discussed in their
| blog. The collaboration features are really what makes Zed such
| an interesting project and product. I was worried they'd gone
| full AI hype train. There's so much opportunity to improve
| digital collaboration tools.
___________________________________________________________________
(page generated 2025-11-13 23:00 UTC)