steveklabnik

I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.

That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.

(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)

Thanks, I'm a Windows user and use Chrome myself, and on my machine it works great, but it's a pretty beefy box. I mentioned this downthread to someone else, but I've filed a bug internally and we'll make sure that it's better optimized. Thank you for the report, it's truly helpful.

I left a lengthy comment below about how we'll be supporting git as well.

I have been a member of this community for a very long time. Posting here is something I just do. jj is already pretty well known here, there's articles about it quite often. But sure, I don't think that anyone would deny that a VC backed startup posting about their product to Hacker News has marketing value. You have to get the word out somehow.

EDIT: oh, this person edited their comment after I replied. There's been a rash of these comments making wild, baseless accusations about Rust developers, thank you dang and the other mods for handling it.

Thanks! I don't have Opera installed on my Win11 machine, but I tried it in Edge and it's barely using anything, but I realize that I have something beefier than a shared GPU on it.

I've filed a bug internally and we'll make sure to take a look. We don't use these animations in the product, only the company site, so this is the first time it's hitting a broader audience. I appreciate the report and sorry about that!

We are not actively hiring at the moment, but will be in the future for sure.

There is active work in this area, yes! https://github.com/jj-vcs/jj/issues/3386 is the bug tracking the feature request, and there have been some recent PRs working on implementing this, see here for one example: https://github.com/jj-vcs/jj/pull/9864

What is your browser/OS combo? Thank you for bringing it up, we can only fix things that we hear about, so I appreciate knowing that something is off.

What is your browser/OS combo? I am assuming it's the animation, we tested it thoroughly but there can always be bugs. Thank you for bringing it up!

It's in the post, but Martin will be continuing to work on jj itself as well as on our products, just as he did at Google, working on the open source jj but also their internal source control team.

As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several other maintainers. The project decided to add more maintainers to keep the balance, rather than ask folks to step down.

We very much want to properly support the upstream project, and we want to make sure that it continues to be awesome for everyone, not just our customers.

As we initially roll out we will be doing that, yes. The reason is that our initial offering is enterprise shaped, and so won't have a self-service onboarding. Eventually we will not require the white gloves, but you have to start somewhere.

Not off topic!

We should be respecting https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A... . If we do not, that's a bug, and please let me know what browser/OS/whatever else combo you have if that is an issue.

It's not so much that we will prevent individuals from using the product, we are just focusing feature development on the needs of companies and teams. Startups are hard, and you have to focus, and so that's where we are focusing first.

This sounds glib, but I mean it sincerely: we will make money by charging money to use the product. A free tier on source control hosting is just not economically tenable nowadays. I have built a career on open source, and so that bums me out, but we have a business to run.

Our moat is that we are not trying to take git and scale it up, we are building a more scalable system from the beginning. And we will have features that nobody else has because of it.

It's always the case that businesses have competitors, that's just capitalism. We're not worried about that.

We have a colopholon! https://ersc.io/colophon

Rust is the default language for all of our non-frontend web stuff, yes.

I wrote a bit about this here: https://news.ycombinator.com/item?id=49526190

I wrote about why I joined the company back when I did previously here: https://steveklabnik.com/writing/i-see-a-future-in-jj/

In short: we are building a next generation source control system for the enterprise.

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site.

While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not possible. And that's the core tech we have built.

With the rise of agents, more and more companies are running into the limits of what Git can do. It was never designed for large monorepos, and so there are performance issues, but also features that it's missing, that are important once you start trying to scale things up to an entire organization. Companies like Meta and Google ran into these things well before the present moment, but you don't have to be a FAANG these days to be running into this sort of stuff.

We also understand that incremental adoption is really important, especially for something as fundamental as source control. So our tech also has a git ingress/egress that will work with the core functionality, but more advanced things that git simply can't do will end up requiring using a non-git protocol. jj is the bridge between those two worlds.

I hope that makes sense! We have been in psudeo-stealth for a while now, this is the start of us coming out of our shell a bit and actually talking about what we're doing.

Thanks!

Martin left Google for this, yes.

Thank you!

We liked our old look, but one funny thing about how things are going in the world: our old color scheme was too close to what happens when you ask Claude to generate a site, and so even though we paid a human to build it, we didn't want to communicate slop, especially because that's not what we did!

Nick Noble is our designer, he put in a bunch of work on this, and I really like it too.

Fixing, thank you!

(Martin joined back then, but we are posting about it today, so we should have the post date as today)

Working with Martin has been a real pleasure, and we'll have some more stuff to talk about very soon!

To further this, "destructive move" as C++ calls it almost happened, but ended up not. So it almost had it the same way as Rust too.

You're welcome!

Just to be extra clear about it, while there's clearly some dysfunction going on in WG21, I don't think Rust's process is free of it either. I do think there's a lot of pros to the way Rust does things, but this stuff is just very hard, in general.

I wish I had actually written "The elephant in the room" back when the safe c++/profiles stuff was going on, but I never actually did. Oh well. Probably wouldn't have changed much anyway.

I mean, what stops it is

> this will likely require some additions to the contract specification.

You need a lot more machinery to move this stuff to compile time, and not everything can be checked at compile time. The first example in the post would require you to validate that a <= v's len before indexing in order to be evaluated at compile time, for example. (Which of course is a runtime check anyway...)

C++ contracts are not a compile-time construct, they're a runtime construct.

Take the example from the article. The contract trips at runtime, not at compile time.

Thanks for this! I vaguely knew most of it but it's great to hear more details.

I think that my misunderstanding here is because I thought that the vote in Croydon back in March was the last chance to veto things, but re-reading https://herbsutter.com/2026/03/29/c26-is-done-trip-report-ma...

> are now producing the final document to be sent out for its international approval ballot

So yeah, I guess in most cases this final ballot is a rubber stamp (not a bad thing, actually, I'd argue it's the way it should be) but maybe this time it is not.

One thing that I'm curious about regarding all of this: I thought all of this stuff landed in C++26, yet we are still getting papers like https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p43...

> The C++26 draft has not yet had its final ballot

This is co-authored by Bjarne, and so I'm sure it's not trivially false, but maybe I am just missing some detail. I know Bjarne was threatening to cast a veto of C++26 over this, but I thought he did not?

Anyone who follows the process a bit more than me have some context here?

It does not disable any checks at all. It adds some unchecked features. All checked features are checked all the time.

Yeah, just to be clear, I am not your parent, I just saw Rust mentioned and realized what was going on in this conversation, ha.

Any time. This stuff took me a while to wrap my head around, since I never worked at Google or Meta. I don't think I'm the best at explaining it yet either...

I’m not sure what a “commit with multiple commits” is. I direct we’re talking past each other slightly :)

I think this is maybe what you’re asking about: with PRs, you often respond to feedback by adding new commits on to the PR. This is because code review is based on reviewing an entire branch. In a stacked diff based system, you respond to feedback by amending the commit. This is because reviews are tied to individual commits, not branches.

The reason people prefer this is that it keeps changes small and focused, and makes sure you have a high quality history. It also lets you assign different reviewers to different parts of your stack, which is helpful for all sorts of reasons. It also means that you can land earlier commits while waiting on review for the later commits, instead of holding it all up at once. Lots of stuff like this.