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

Zed DeltaDB

zed.dev

Post reply on HN
Print view View original

211–220 of 326 posts

Re: Zed DeltaDB

#211

Post by pjmlp »

rozap wrote: post #123
NoDodgeQuestion wrote: post #6

Zed should focus on basics. When it focuses on basics Zed is good. https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL. Why a new version control system? Why not git, jj, or another existing system?

It's funny, zed started out really refreshing, and now it's degraded to the point where it's fairly unusable. Regularly it would tie up tons of resources on my fairly beefy laptop. I switched back to sublime and it is a breath of fresh air, I didn't realize how slow zed had gotten. It seems like maybe they lost their way a bit, but I recognize that also they need to make money presumably, and it's hard to do that wit…

And yet it is written in Rust, a good evidence that compiled languages only help so much when the architecture isn't the right one, or bad algorithms are being chosen.

Re: Zed DeltaDB

#212

Post by adamnemecek »

hresvelgr wrote: post #210

Commercially speaking, going against Git is a fool's errand. As much as I'd like to see Git usurped, I can't imagine the people backing this would sign off on a competitor to Git unless it was some type of sidecar. No doubt it'll be tightly coupled to Zed as well which is concerning. Perhaps this is pessimistic but I don't have faith the team are going to deliver anything groundbreaking given their entire business is…

Dude the writing is on the wall, git had a good run but it's time for something else. Lore is also solid.

Re: Zed DeltaDB

#213

Post by pjmlp »

WD-42 wrote: post #151
pzmarzly wrote: post #145

Earlier quoted context omitted.

I would like Zed to have feature parity with VSCode from 6 years ago. Working well over SSH or WSL, which it currently doesn't, is a part of that, even if I don't use that everyday. I am a paying user, and have no plans to stop supporting them financially, but I wish they locked in and went through GH Issues queue, starting from the oldest.

Of course vs code accommodates wsl. Same company. Personally I couldn’t care less how badly MS wants to make windows a viable development environment. It’s more irrelevant every day. I’m glad zed doesn’t waste too much time on it.

Windows is more than viable as development platform, ask Valve why they need Proton in first place.

Re: Zed DeltaDB

#214

Post by rolymath »

hresvelgr wrote: post #210

Commercially speaking, going against Git is a fool's errand. As much as I'd like to see Git usurped, I can't imagine the people backing this would sign off on a competitor to Git unless it was some type of sidecar. No doubt it'll be tightly coupled to Zed as well which is concerning. Perhaps this is pessimistic but I don't have faith the team are going to deliver anything groundbreaking given their entire business is…

That's what people would have said 3 years ago about going against google (and search engines in general), yet here we are.

Revolution is in the air.

Re: Zed DeltaDB

#215

Post by norman784 »

rozap wrote: post #123
NoDodgeQuestion wrote: post #6

Zed should focus on basics. When it focuses on basics Zed is good. https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL. Why a new version control system? Why not git, jj, or another existing system?

It's funny, zed started out really refreshing, and now it's degraded to the point where it's fairly unusable. Regularly it would tie up tons of resources on my fairly beefy laptop. I switched back to sublime and it is a breath of fresh air, I didn't realize how slow zed had gotten. It seems like maybe they lost their way a bit, but I recognize that also they need to make money presumably, and it's hard to do that wit…

Did you check if the resources were consumed by the LSP or Zed? Also there was a Zed fork without the AI stuff, not sure if is a hard fork or not and if is still maintained (IIRC wasnt hosted on Github)

Re: Zed DeltaDB

#216

Post by wodenokoto »

I think there is a ton of value of being able to rewind in between commits. I always felt that asking for a description of a commit is way too much.

I can write a bunch of checkpoint commits and then squash them, I suppose, but the interface for doing it isn't super inviting and there are a lot of things I need to consider in terms of tracked and untracked files.

If I understand this correctly, I can deltaDB all my untracked and ignored files and git push my thought-out commits, fully respecting things ignored. And If I realise that I should have git-commited 10 minutes ago, I can rewind, commit, fast forward and continue.

Re: Zed DeltaDB

#217

Post by eviks »

TacticalCoder wrote: post #108
pknopf wrote: post #9

A non-existent problem that nobody asked to solve...

They say that "history between commits" matters. If it's really so for some people, a case could be made that their problems can already be half-solved by changing the granularity of their commits: just commit more often.

What about the other half?

Re: Zed DeltaDB

#218

Post by darkwater »

dlisboa wrote: post #87
NoDodgeQuestion wrote: post #6

Zed should focus on basics. When it focuses on basics Zed is good. https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL. Why a new version control system? Why not git, jj, or another existing system?

There should be a concept called "engineering privilege". I see some companies do things that are widely out of their core product and engineers there just having fun with a bunch of different stuff with seemingly no commitment to bring in revenue. They'll re-invent/re-write things constantly, write a new compiler/package manager for their chosen language, create new frameworks, new open source projects unrelated to…

And the cherry on the cake: you get paid to work on your engineering project, get traction around it as opensource and if there is enough traction, leave the company and spin-off a new one to sell the same product to other companies!

It's surely a lot of work but you get basically the discovery phase til market fit with your ass covered. Kudos to the engineers that pull that out, I really mean it!

Re: Zed DeltaDB

#219

Post by TiredOfLife »

NoDodgeQuestion wrote: post #6

Zed should focus on basics. When it focuses on basics Zed is good. https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL. Why a new version control system? Why not git, jj, or another existing system?

Thank you for finally explaining why open source developers hate AI so much. If their bug reports are all like this AI sloprambl.

Re: Zed DeltaDB

#220

Post by nirvdrum »

AlotOfReading wrote: post #170
nirvdrum wrote: post #86

Earlier quoted context omitted.

Have you checked your fs.inotify.max_user_watches value? Maybe your value is too low and Zed can't watch the files that are changing. I know the JetBrains IDEs need the default to be increased on Linux because they detected it and prompted me to increase it.

Even if that's the case, max_user_watches is never less than 8k unless you've set it lower for some reason. If the editor is prioritizing currently open files as it should, there should basically never be a problem even if project sync suffers.

The limit is per-user, not per-editor. Every process under your UID shares the same max_user_watches pool. So the editor's "prioritize open files" behavior can't help when a resident daemon like Watchman has already consumed the budget. Zed doesn't error out when it hits the watch limit. It logs a warning and periodically retries to establish the watch. Until it can do so, external file changes aren't reflected in the editor.

I just checked my workstation and found Watchman alone holds ~556K watches across 34 roots. It keeps those watches even after the tool that spawned it disconnects. Notably, I've never invoked Watchman manually -- other tools do. And the 8k floor isn't much of a floor. My nixpkgs checkout alone is 37,686 directories, 4.6x that.

Truthfully, I had no idea Watchman stays resident and accumulates watched roots. But, that's kind of the point. It's a very easy thing to miss.

Post reply on HN