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

VisualJJ – Jujutsu in Visual Studio Code

visualjj.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: VisualJJ – Jujutsu in Visual Studio Code

#51

Post by wenc »

hippo22 wrote: post #14
Yeroc wrote: post #12

Earlier quoted context omitted.

Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.

I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emer…

> For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.

This is an interesting opinion.

I feel we are nowhere near the terminal state for programming languages. Just as we didn't stop inventing math after arithmetic, we will always need to invent higher abstractions to help us reason beyond what is concrete (for example, imaginary numbers). A lot of electrical engineering wouldn't be possible to reason about without imaginary numbers. So new higher abstractions -- always necessary, in my opinion.

That said, I feel your finer point resonates -- about how new languages might not need to be constrained to the limitations of human ergonomics. In fact, this opens up new space of languages that can transcend human intuition because they are not written for humans to comprehend (yet are provably "correct").

As engineers, we care about human intuition because we are concerned about failure modes. But what if we could evolve along a more theoretical direction, similar to the one Haskell took? Haskell is basically "executable category theory" with some allowances for humans. Even with those tradeoffs, Haskell remains hard for most humans to write, but what if we could create a better Haskell?

Then farther along, what if we created a LEAN-adjacent language, not for mathematical proofs, but for writing programs? We could throw in formal methods (TLA+) type thinking. Today formal methods give you a correctness proof, but are disconnected to implementation (AWS uses TLA+ for modeling distributed systems, but the final code was not generated from TLA+, so there's disconnect). What if one day we can write a spec, and it generates a TLA+ proof, which we can then use to generate code?

In this world, the code generator is simply a compiler -- from mathematically rigorous spec to machine code.

(that said, I have to check myself. I wonder what this would look like in a world full of exceptions, corner cases, and ambiguities that cannot be modeled well? Tukey's warning comes to mind: "Far better an approximate answer to the right question, than an exact answer to the wrong question")

Re: VisualJJ – Jujutsu in Visual Studio Code

#52

Post by steveklabnik »

tuwtuwtuwtuw wrote: post #50
steveklabnik wrote: post #26

Earlier quoted context omitted.

It uses it when you use the git backend, but not when you don’t. Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.

For anyone that does not work at Google, it sounds like an implementation detail that does not matter.

Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git.

To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.

Re: VisualJJ – Jujutsu in Visual Studio Code

#53

Post by 3eb7988a1663 »

surajrmal wrote: post #21
misnome wrote: post #11

Earlier quoted context omitted.

10% revenue to google?

While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.

I mean the Google CLA kind of says otherwise.

Re: VisualJJ – Jujutsu in Visual Studio Code

#54

Post by capitainenemo »

SAI_Peregrinus wrote: post #20
AbuAssar wrote: post #8

Earlier quoted context omitted.

it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.

Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.

Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN)

The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.

Re: VisualJJ – Jujutsu in Visual Studio Code

#55

Post by desmondwillow »

hippo22 wrote: post #14
Yeroc wrote: post #12

Earlier quoted context omitted.

Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.

I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emer…

I'm quite surprised to hear that "programming languages have reached a terminal state": there are (imo) at least four in-progress movements in the industry right now:

1. Memory safety 2. Better metaprogramming capabilities 3. Algebraic effects 4. Solver/prover awareness

Even if LLMs become capable of writing all code, I think there's a good chance that we'd want those LLMs writing code in a language with memory safety and one amenable to some sort of verification.

Re: VisualJJ – Jujutsu in Visual Studio Code

#56

Post by dwattttt »

KingMob wrote: post #28
lima wrote: post #3

There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk

jjk caused a lot of problems for me when using multiple agents. It's running some sort of jj command that snap-shotted stuff and caused divergence (might have benefited from `--ignore-working-copy`). Not sure what the precise details were, but I gave up and uninstalled it after a week.

Multiple agents is definitely tempting fate. Concurrent modification of the same git repo by multiple entities?

At that point you should use multiple repos so they can merge & resolve.

EDIT: of course, if a single agent uses git to modify a repo instead of jj, jj may have trouble understanding what's happened. You could compare it to using an app that uses an sqlite db, and then also editing that db by hand.

Re: VisualJJ – Jujutsu in Visual Studio Code

#57

Post by dwattttt »

Okkef wrote: post #10

I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools. Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fal…

I wonder if you could replace the git commands exposed to an agent.

A 'commit' 'happens' when you leave a change in jj, i.e. by moving to a new or existing change; that's when you'd run pre-commit hooks.

Re: VisualJJ – Jujutsu in Visual Studio Code

#58

Post by steveklabnik »

dwattttt wrote: post #57
Okkef wrote: post #10

I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools. Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fal…

I wonder if you could replace the git commands exposed to an agent. A 'commit' 'happens' when you leave a change in jj, i.e. by moving to a new or existing change; that's when you'd run pre-commit hooks.

The problem with this is that at the limit, this means "run the precommit on every save of a file," which is not really usually how people think of precommit hooks.

Re: VisualJJ – Jujutsu in Visual Studio Code

#59

Post by rtpg »

steveklabnik wrote: post #58
dwattttt wrote: post #57

Earlier quoted context omitted.

I wonder if you could replace the git commands exposed to an agent. A 'commit' 'happens' when you leave a change in jj, i.e. by moving to a new or existing change; that's when you'd run pre-commit hooks.

The problem with this is that at the limit, this means "run the precommit on every save of a file," which is not really usually how people think of precommit hooks.

Given jj's rebasing tooling, rewiring precommit into "prepush" feels like the right way forward. There's a bit of a phase transition between commits on your machine and commits that are out in the wild, after all.

Re: VisualJJ – Jujutsu in Visual Studio Code

#60

Post by rtpg »

bergheim wrote: post #24

If anyone uses frontends like magit - what is the usecase for this? I feel like git is just easy-mode with magit and I don't really miss a whole lot more. I totally get this is you are using the git cli or some such. Might just be my limited imagination though of course.

rebasing, rebasing, rebasing.

I used/use magit a lot, and rebasing is much nicer with magit. But you're still faced with having to be in git land. JJ there's a lot of "rebasing at the speed of thought" because you really are just moving nodes around and "do what I mean" kicks in.

There's this other thing too, which is that jj I've always felt comfortable modifying changes that are not what I currently have checked out. With git it's always felt like the first step for any change management is "check out the changes into the working copy".

Post reply on HN