steveklabnik

Those are evaluated at compile time, C++’s aren’t guaranteed to be, they’re runtime checks.

Yeah, I'm not saying C does, just that Rust's features aren't limited to "helping you with heap memory." Rust is also more than lifetimes.

Rust doesn't have heap allocation in the language at all. It still has useful features regardless.

> Rust has no reason to touch the original Unix API.

As a systems language, Rust must provide access to the APIs of the underlying system, and on UNIX, that’s, well, UNIX.

I was born in Butler!

Okay, yes, I agree that that’s how it works. I thought when you said MUST you meant that it doesn’t work; it does work it’s just that it burns a turn or two to do the lookup there. I certainly agree it would be nice to not do so.

(And I didn’t know the double args thing, that’s very interesting! I should have said I only meant the first bit.)

The 30,000 number is across their entire monorepo, which they say in the article Claude Code does not live in.

I have done exactly this as recently as yesterday, so I’m not sure why it doesn’t work for you.

It also did find bugs in the old code and contributed tests to their suite.

Makes sense, all I wanted to point out is that this is a real problem for some real companies.

It is sort of semi-ironic to suggest this in this thread, but you can ask Claude about why Facebook created Mononoke and Sapling, and where git has scaling issues. It will give you good answers.

Microsoft did, but that doesn't change the limitations imposed by git's design. Their repos just weren't as large.

> under 1 commit per second

Sure, for arbitrary pushes, that's not a big deal. But for large repositories, with those changes landing on trunk at that rate, once you start talking about "commits per second" it gets very difficult.

To be clear, we are not building a build system, just a VCS. :) we do use buck2 internally though.

I do care about Windows, having used it for years at this point. The client is git or jj, so Windows support is there for sure. For some of the other stuff we’re doing, we’ll see what customer demand is like. Obviously there are tons of devs on Windows, but we also have to make calls about priorities too.

Google and Meta hit these sorts of limits over a decade ago. They then built new VCS stuff to handle it, Meta's part is the subject of this submission. This was even pre-agents.

Git is just not suited to truly large monorepos, and it won't ever be. That's totally fine, of course. Less of a monoculture here would be great.

Rust NYC is certainly one of the things I have missed since moving to Austin :)

Maybe, we'll see. I think one thing that's tricky these days with startups is that being super transparent technically about what you're up to is much harder to justify. Look what happened with Origin: tobi vibed up a copy over the weekend after it was announced. Obviously there's balance to be found here, but that's partially why we play our cards a little closer to our chest.

The startup I work at is working on exactly this. So I agree :)

(Okay not literally exactly, for example, jj/git not hg. But the vibe is the same.)

I see a lot of non-technical people who both criticize "AI" and use AI heavily. Same sort of "without real understanding" you're talking about. I think software developers tend to expect a lot more consistency in people than they actually have. Software developers included, which is kind of ironic.

> be prepared to see a whole lot of ‘Linus using vibe code Linux going to crash lololol’ type of posts

I mean, we see a lot of this in the developer community as well, already.

I recently attended an academic computer science conference. Several people I have looked up to my entire life were there, which also gives you an idea of their age (I am 40). They're all using AI. They are not mindless boosters about it, but clearly find it a useful tool in the toolbox.

Rust isn't tied to a language-level build system. You can use plain old rustc to your heart's content. I don't use Cargo for any of my own projects any more.

People tend to use it because they like it.

Ah, yes, you can do stuff like that too, for sure.

At some point you still end up running into the issues the article talks about, all of these approaches only get you so far.

> "fetched naively" here means doing a full `git clone` on every need for `git checkout`, which of course nobody should do,

It can be cheaper to do a full clone than a shallow one, because with the shallow one, you can't re-use packfiles. GitHub has fairly regularly asked people to stop doing shallow clones because it's harder on their servers than full ones.

Thanks :)

I have not personally considered that, no. I'm a bit skeptical of the idea, as you'd need to understand a lot of different things, and at different versions of those things, in high fidelity. But maybe someone will make it work.

Just to be clear about it, what we're doing is not a forge like GitHub, that is, a large single public platform for social coding. What we are doing is providing reliable infrastructure for the enterprise, initially as a BYOC on-premises option, and possibly a single-tennant SaaS. Keep your eyes peeled and/or use that contact form to hear about it when we're ready, we've been talking with some people for a bit but are going to be opening up more soon.

Tangled is doing the social coding thing, and they're jj-native as well. Been a big fan of their work for a while now.

Yep, we've been in stealth for a while! We've only recently started talking more about what we are doing, as we get closer to a general launch.

> if the vibe coding idiots like it,

The organizations that have these problems are general large enterprises, not vibe coders. Large enterprises are more used to talking to people and do not make decisions solely based on the contents of a web page.

I apologize for what may come across as a bit of a cop-out answer.

As many of you know, I'm a big fan of jj. The jj project used to have a comparison to Pijul for informational purposes, but the Pijul folks took offense, and so it was removed: https://github.com/jj-vcs/jj/commit/0525dc9d860a5fff6a97d134...

As such, I generally just decline to comment on Pijul, as I want to be respectful of them. As the linked commit says, it's not super clear what exactly they do not like, and so I don't want to accidentally cross some line.

In general I wish the project well, seeing a new VCS in Rust is very cool.

Very excited to see this come out of Anthropic! This[1] is what we believe over at East River Source Control as well, and seeing one of the big labs talk about it really validates our thesis.

We are offering a bridge to git via a compatibility layer: https://ersc.io/blog/what-comes-after-git

This gives you the ability to ease your transition, as you don't need to swap services and move to something non-git at once. Moving an enterprises' source control is a massive lift, and so building a bridge from here to there is a big focus of what we're doing.

1: That is, if you have a large team + agents working in a monorepo, you will hit git's scaling limits, and need to move to something else. Google and Meta hit this point over a decade ago, but now lots of other companies are too.

That's fine. My aim is to clarify Rust's design and choices. I don't have strong opinions about what should be in the post.

> I'll add that the essay has a footnote saying

Honestly I have an entirely different beef with this footnote: `chars` is for codepoints, not really "characters", because what a "character" is in Unicode is very complicated.

> My follow-on presumption is that most Rust libraries use this sort of idiomatic production code, where allocation failures simply panic.

Yes, I wouldn't argue that most Rust code uses these try_ variants, because of the whole overcommit thing. But in contexts where it does matter, people do. The expectations are different based on context. Lots of Rust code expects (and enforces) no allocations at all, but that doesn't mean I'd claim that all Rust code does.

I also think it's fine to want to hold libraries, C or Rust, to a higher standard with regards to allocation failure, but in practice, most people (in both languages) do not find the juice worth the squeeze, and so don't really do it.

> Its less trouble to setup static analysis, address sanitizer, and similar tools for a C project than it would be to manage local copies of thousands of dependencies for a Rust project.

It is trivial with Rust to set up asan and friends. You just

  $ RUSTFLAGS=-Zsanitizer=address cargo build -Zbuild-std --target x86_64-unknown-linux-gnu

And you’re off to the races.

This works for your dependencies too. This isn’t C, you don’t need to manage all of those builds individually. That’s what the build system is for.

> I don't think my software is all that special.

I think that regularly requesting a single chunk of memory that is likely to be larger than total RAM + total swap in the desktop context is unusual, but it's true this is an opinion.

> The linked-to essay uses new_uninit_slice in Rust

If you wanted to check the allocation, you'd use try_new_uninit_slice, which is the same thing but returning a Result instead of panic-ing.

> where the default is for Rust to handle OOM errors,

Again, it's worth splitting out the language from the library and or culture here: Rust itself never allocates, and so never OOMs.

> also holds for the C code.

I don't mean to imply Rust is better than C in this regard, only that "you can't check for OOM in Rust and therefore it's impossible to build the library how I want" is untrue.