They run a Rust consultancy business. Anything is worth converting to Rust, for the right price.

Sounds like we just need a Dyson sphere.

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.

Markov chains are very useful and imo so are LLMs, the issue I believe stems from calling it "inteligence" which creates some expectation which is often not met

Most of your comment history is defending LLM psychosis

Most of your comment history is less than a month old

This. I feel jj is some years too late.

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.

A lot of humans don't currently trust agents to touch VCS today. I also find that my agent tends to be much better about dealing with jj than it is with git.

Culture change is hard.

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.

That's the beauty of jj. It doesn't need critical mass. If the community remains small it's fine. If it blows up in adoption that's also fine.

Also there are many ways to use llms. Some people control it at code review, but others control it as the VCS.

Sure just like any non-critical tool. It's optional.

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.

jj is in the training data for at least Gemini these days. My experience is it uses less tokens to do similar workflows with jj vs git because they are simpler.

Also, remember that humans aren't going away. The touch points are changing but they still exist. The VCS is a common touch point for many and my preferred one. For others I'm sure it's online code review tools. If an agent is operating under my name in my workspace I want to manage it within the confines of my workspace. Once it becomes more agentic and operates as it's own entity I'm sure I'll change my mind but that's not the case today.

I'm one of those people. I don't really use jj, but want to give it another try. Think I'd feel more comfortable letting ai mess with jj because of its excellent ability to undo/redo (op log).

Good git hygiene is also less important post-LLMs, as the LLM can make sense of even a messy history.

Correction: The use of LLMs has caused every major language usage to explode.

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.

Fully agree with this. We use Rust in an enterprise setting for building web app backends and the experience is painful. A lot of crates just seem like someones side project. Too many ways to do things leads to bike shedding in PRs. Compile times are atrocious and can take like 30 mins to build.

Honestly using Go would have got us to the same point much quicker, with code that is much easier to review.

> And it's not just speed, Tauri takes 20GB of disk space to compile

I’ve worked with enough UI frameworks and large applications that this doesn’t sound unreasonable. It’s a smaller disk footprint than I’ve needed for several other C++ codebases with similar scope.

Do you boycott Apple and Google too? Because they have to comply with debatable laws just as Meta. See drama about Apple maps for Taiwan/China for example.

> There is no ulterior motive here.

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.

Sure, but I don't and nor do most of the jj community. esrc has less than 10 folks working on it, the number of jj enthusiasts is massive.

It has potential to remodel society though.

Cars replaced horses.

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

Where's the ceiling?

> Where's the ceiling?

A stable civilization that doesn't devalue human life and well-being to the point of absurdity.

thats the ideal ceiling, but I don't see why we won't surpass that.

> People just need to calm down

I think people need to make sure ceilings are built, and we can calm down once we're done.

If they buy Cursor I might start using it because I'll know the tool will have infinite funding and will be worth my time investment.

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

And it is screamingly fast.

When you say DeepSeek v4... you do realise it is a 1.6T param model right?

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

For core system functionality maybe. But for most applications Rust slow compiler iteration speed becomes a bottleneck when the likes of TypeScript (with Bun) and Go have sub second iteration times.

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.

In my experience developing different types of applications in Rust, the claims of a "slow compiler" are overstated. Sub second iteration times are definitely a thing in Rust as well, unless you're adding a new dependency for the first time or building fresh.

Our experiences clearly differ then. And for others as well since it's a common complain.

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.

I think you could have left it at differing experiences and not gone further saying I'm handwaving anything. That doesn't seem productive.

I'm not saying that Rust compilation time is comparable to Go/TS, I'm saying the blanket claim that Rust iteration speed will be a bottleneck requires context.

I definitely agree with you that it is a complaint that is often repeated online, but that doesn't make it universally true. In my experience it's a claim that is often echoed without proper context.

Particularly in the case of AI Rust recompliation times in my experience have not been the dominant cost, but are instead overshadowed by inference time, the agent working through different approaches, etc.

The productivity increase I get overall by not having to worry so much about if my rust code will work if it compiles tends to net faster iteration speeds for me. Compile times have never bothered me.