steveklabnik

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.

> How is it then that my stock KUbuntu system won't let me allocate 50,000,000,000 bytes?

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.

To be specific, I’m talking about try_ variants of functions that allocate and return Result.

I’m not sure when those are becoming stable, but Rust for Linux has been driving a bunch of this work, in my understanding, so that’s helped a lot.

The Rust stdlib has added those functions that return errors, and the types are parameterized by the allocator trait. The trait is coming to stable in the next release!

> I think it's because

It’s not any of that. It’s because of overcommit being the default for basically every Linux system. With that, malloc will never fail, and it’s the later access of that memory that will. In practice, you’ll virtually never see malloc actually return a failure, and so most software, no matter the language, is generally not robust to this condition.

(And CHAR_BIT is required to be 8 by POSIX, so even though the language and some exotic hardware will have it at non-8, it’s exceedingly rare at this point.)

I think that you are (naturally) approaching it from your side, and they're (naturally) approaching it from theirs, and it sounds like it's not a fit. That's a successful outcome for a hiring process.

Oxide's process involves submitting writing with various questions about you, what you've done, and what you're looking for in your career. The process of doing so inherently means reflecting on the answers to those questions, and so some people find it a useful exercise.

I wrote this back in 2022 when I worked there, and it's still fundamentally relevant today: https://news.ycombinator.com/item?id=30678324

When I worked at Oxide, you only get to the interview part if you’re extremely close to an offer. Like, down to one or two candidates out of hundreds.

I saw recently that someone had ported Halo CE to the web and had 1024 players in Blood Gulch.

A recent one for me is Anthropic's first party cloud stuff all assumes you're cloning from GitHub.

It's the same reason that I don't use bitcoin for large purchases: I want the ability to have disputes handled if and when something goes awry. With cash, I have no recourse.

> as well as the contract with the provider

It used to be here in the US, but there was enough violations that they stopped putting it in the terms.

But, looking into this, it looks like some states have made it illegal. I'm curious how well that's enforced.

> Consumers would flip in a heartbeat if shops were allowed to offer discounts to those not using credit cards.

We must be very different consumers.

Also, many places already do effectively this, they charge a surcharge for using a card.

There are dozens of us who both play Marathon and care about the Rust compiler. Dozens!

Yep! All good info.

That sentence is specifically talking about not initializing with a placeholder value, and instead letting it write over uninitialized values.

One of the hardest parts of optimizations is not being penny wise and pound foolish. This sort of thing is a great example of that.

Additionally, a hard part is that all of this can change over time with new hardware! Some patterns that were crucial before everything gained branch predictors are irrelevant now, etc.

usually with Rust impactful savings come from writing the Rust differently, not from doing hand-written assembly instead.

See stuff like https://davidlattimore.github.io/posts/2025/09/02/rustforge-...

This doesn't mean Rust is near perfect, it's just that your first move should be "how do I make the Rust better" and not "I need to drop into asm."

I didn't really phrase this particularly well: I meant that you cannot determine this stuff at compile time because it is inherently a runtime analysis. Of course the compiler could emit the Miri interpreter into a binary if people chose to put the pieces togehter that way.

1. You've got the causality backwards. LLVM backends don't come for free, you have to write code to enable support for them.

2. LLVM does not support as many backends as GCC does, so even if you did get 100% of the LLVM supported backends up and running, you'd still be missing some.