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

101–110 of 326 posts

Re: Zed DeltaDB

#101

Post by benjiro29 »

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…

Because every company may have different needs that are not fulfilled by standards software. We have seen the large number of companies whose goal is to make custom software for other companies So is not always that reinventing is fun, but it may actually be needed.

The same logic also applies for software that is used internally. It's not always that developers want to rebuild stuff, but that they need to rebuild or alter software to fit their / company needs.

We have not even talked about cost or licensing or other issues.

Re: Zed DeltaDB

#102

Post by ralusek »

Can maybe think of one time in the last 10 years that I would have wanted this. Its only purpose is for training LLMs

Re: Zed DeltaDB

#103

Post by thangalin »

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?

From 1996:

https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...

"There is the software. And then there are the databases beneath the software, two enormous databases, encyclopedic in their comprehensiveness. One is the history of the code itself -- with every line annotated, showing every time it was changed, why it was changed, when it was changed, what the purpose of the change was, what specifications documents detail the change. Everything that happens to the program is recorded in its master history. The genealogy of every line of code -- the reason it is the way it is -- is instantly available to everyone."

Re: Zed DeltaDB

#104

Post by exe34 »

spockz wrote: post #47
exe34 wrote: post #30

Earlier quoted context omitted.

Like a branch on the server?

That would still be in git. The local history in IntelliJ works independently of any VCS. Also I’ve had formatters botch files including changes I hadn’t committed yet. For that the local edit history is also useful.

Or add it to git? What's wrong with git?

Re: Zed DeltaDB

#105

Post by Valodim »

ibejoeb wrote: post #41
xlii wrote: post #32

I start to sound like a Jujutsu fanboy but... Jujutsu already does this. I had agent screwing up changeset over couple hour long session and it took one shell command to split on pieces with longer pause. The only downside is that because of Jujutsu snapshots it can't be used inside sandbox (since all jj commands are mutating)

Jujutsu is great, but it does not do this. It has no knowledge of agent sessions.

You still get snapshots of the working tree every time an agent calls a jj command, including reading ones. This is regular for me that I'm not worried to lose any intermediate state.

Re: Zed DeltaDB

#106

Post by cannonpalms »

ibejoeb wrote: post #39
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?

I agree with you that I wish they'd just nail the editor. I've been using it for years now and I really like it, but there are a few rough parts (settings and LSPs especially) that could probably be tuned up in no time if the focus was there. Having said that, I love the idea of correlating the agent sessions to the changes. I'm glad someone is working on it.

Claude, for example, already does write a git commit trailer with a session ID.

Re: Zed DeltaDB

#107

Post by echelon »

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…

> Every change is linked to the agent conversation that produced it. From any line of code, find the conversation. From any message, jump to the code it touched.

This is how Zed leapfrogs the field and becomes a centicorn.

If you can train a model to operate at a higher level and with looser requirements, you've gotten rid of engineers in the loop and built a system for the automated synthesis of high quality software.

You're training systems to produce higher quality chain of thought across the entire software development lifecycle.

This is training data for the next stage.

Re: Zed DeltaDB

#108

Post by TacticalCoder »

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.

Re: Zed DeltaDB

#109

Post by nxc18 »

jackling wrote: post #78

I really do like Zed, it's snappier than VS code and with pretty good vim emulation. Even through SSH, the native UI allows for no network latency, compared to something like vim+terminal. Like many other posters, I do feel like the core editor is getting worse. Some issues I've encountered recently at work: - Routinely encounter bugs with the python language server, it's particularly slow when compared to using VSCo…

Yeah apparently Zed was engineered for speed but I find it very slow in general, especially on startup.

VS Code can slow down as you add functionality, but Zed often just doesn’t have that functionality at all. So the proper comparison is “VS Code minus all extension-provided features” which is actually pretty fast.

Post reply on HN