Comments URL: https://news.ycombinator.com/item?id=48411686

Points: 4

# Comments: 0

LLMs will do most of the work anyways. And they don't need jj. Like I said, jj helps solving a human problem in an LLM era.

It's hardly worth using more of the precious LLM context with jj instructions when git does the job and is mandatory anyways.

Besides, I have been hearing "this is the limit" since the doomers of "this is just a markov chain and can't be useful".

Yet the limits keep being broken.

A lot of humans still don't use git too.

Many do only when they are forced.

And it's much easier for a professional to be forced to use LLMs than jj when it comes to versioning assist (not even comparable in mindshare but the obvious needs to be said sometimes).

So unfortunately I'm afraid jj is not going to achieve critical mass before 99.99% of merges are done by AI which don't need jj.

It tries to solve a human problem in an LLM era.

LLMs are destined to overcome humans in code merging and change versioning (already did for me).

There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.

And as mentioned in other comments, Rust slow compilation can be detrimental to LLMs + fast iteration speed. And it's not just speed, Tauri takes 20GB of disk space to compile. It's bonkers. This is npm/js ecosystem all over again but slower.

Another reason to pick Go if you're leaning on LLMs is the standard library. Often you can do more work with fewer dependencies.

I'd rather leverage world class engineers paid by Google to maintain dependencies for me than try my luck with half a dozen of 0.x crates. Plus stdlib APIs can (and are) versioned just like third party dependencies.

I just want to point out that it is known that one of the biggest jj proponents on HN does have financial incentive to do so.

Steve Klabnik (the person that submitted this post) comments and posts about jj here often and works for https://ersc.io (startup mentioned in the post).

So don't be so sure that all of the PR here comes from a pure selfless act. Some of them have income tied to the solution they are preaching.

Cars replaced horses.

But AI is poised to replace a large chunk of brain labour.

Where's the ceiling?

Specially because Grok isn't neutered when it comes to security scans.

And it is screamingly fast.

What kind of consumer hardware can run it reasonably in your mind?

Countless time I have seen other people complain as well. There are articles about it even. Can't find the YouTube link now but recently a gamedev abandoned Rust due to compilation speed alone because iteration speed was paramount to their creative process.

Handwaving isn't going to make it any better. And thinking Go/TS compilation speed are comparable to Rust is, a handwave and a half to say the least.

Cargo check and friends are subpar for AI because they actually need to run the thing and unit tests for efficient agentic loops.

A single loop might recompile and rerun the application/unit tests enough times that slow compilers like Rust and Scala become detrimental.

Plus AI is also good at catching, in other languages, errors that Rust tooling enforces. Like race conditions, use after free, buffer overflows, lifetimes, etc.

So maybe AI will become to ultimate "rust checker" for any language.

And DeepSeek V4 Flash is comparable to Gemini Flash at also a fraction of the cost.

These models are just quite chatty from my experience. Only downside.

And DeepSeek is planning to deploy to their own Huawei TPUs, halving their already cheap prices.

This was bound to happen, AI or not.

> Because Railway stores volume-level backups in the same volume — a fact buried in their own documentation that says "wiping a volume deletes all backups" — those went with it.

Intelligence comes in many forms. This decision is one of them.

But I think "context switching" between 2 different prompts might be too expensive for GPUs to be worth it for LLM providers. Who knows.