steveklabnik
As a systems language, Rust must provide access to the APIs of the underlying system, and on UNIX, that’s, well, UNIX.
(And I didn’t know the double args thing, that’s very interesting! I should have said I only meant the first bit.)
> 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.
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.
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.
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.
(Okay not literally exactly, for example, jj/git not hg. But the vibe is the same.)
> 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.
People tend to use it because they like it.
At some point you still end up running into the issues the article talks about, all of these approaches only get you so far.
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.
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.
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.
> 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.
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.
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.
> 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.
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
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 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.
Assuming that it has the default overcommit setting, it's based on a heuristic. Currently, that heuristic is something like "is this single allocation larger than all of physical memory + swap", if I remember correctly.
However, most real software does not try to allocate like this. It allocates reasonably small chunks of memory regularly. So again, in realistic conditions, you generally won't see a failure.
> Daniel Stenberg of curl fame is a developer of robust software who does not appreciate how Rust handles out-of-memory errors makes it impossible to implement libcurl in the way he expects a library to work
I am not re-watching this video right now, and of course have a lot of respect for Stenberg, but either he or you misrepresents the situation here: allocation is purely a library concern in Rust, not a language one, and so you can absolutely write your own code that allocates memory however you'd like. This is a concern about Rust's ecosystem, not about the language itself. It is surely not impossible to do this, embedded folks write Rust that doesn't even have an allocator present regularly, let alone infallibly allocate.
> 4.5 years ago
As I mentioned elsewhere in this thread, the standard library types are gaining methods that return Result instead of panic, and have had them for a long time, though they've been nightly only, since it's a pretty niche case.