steveklabnik

Okay I've been thinking about this a lot lately, and here's my "I'm currently drinking my coffee" take on this. I'm willing to be significantly wrong here, but for the sake of discussion, here's where I think I'm at.

I also agree with

I love it when AI tools are used to give people the ability to solve problems that previously they could not solve well.

But I also really hate these menus, I see them all the time as well. I think that my conclusion is slightly different than yours: in my opinion, just not a lot of people have taste. That's sort of like, true by the definition of taste, but what I mean is something more specific: it's not because of AI that I dislike these signs. It's because of what you said above:

producing something that genuinely looks like a huge improvement to them.

While it looks like a huge improvement to them, it does not to me. Our tastes differ.

Here's a version of this that doesn't involve AI at all: last night I ate sushi at a place I'd never been before. Their menu was a bit chaotic, and had a bunch of annotations, along with a guide to those annotations. One section had both "2" and "2 pieces" listed under the options, and so I was confused: what was the difference here? Turns out it's basically just a typo, both mean that. Combine that with some spelling mistakes, and yeah, I had a pretty bad impression of the menu. The sushi was fine though, I'd go back. But this wasn't a super low-end place, so the attention to detail being off made me a bit worried before I actually ate the food.

Same problem, same issue, AI is really the only variable here. And it is the natural downside of "democratization" or "helping more people do more things", naturally, there will be a lot more low-quality stuff out there than before. That's not actually inherently a bad thing. But it can feel weird.

Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.

Memory safety is necessary, but not sufficient,

I fully agree!

This paper uses models that are over a year old at this point. Many people didn't believe that LLMs were worth using for programming until 6 months after that, and now again this week we've had another huge leap in abilities.

This is beyond the other issues with the methodology of this study. For example, their Rust code was created by asking Deepseek to port their C++ code, not having it try and write Rust itself.

They aren't exactly the same thing, moving to node would be possible but bun does more than node, so you need to replace the whole thing.

Every compiler has bugs.

I fully agree that there are similarities here. But we disagree about some of the details.

you have essentially zero protection in Rust that helps you with finding Node-s that have been used for something else etc.

The most obvious technique is generations. You can of course do that in Zig as well.

if you do use-after-free on a page claimed by the OS,

This assumes that you're working in the context where there is an OS. That isn't always the case. Also, there are other cases than just use-after-free: for example, compilers will optimize around null pointers being UB, which can cause other problems, whereas an index of zero does not get the same treatment.

But also, again: Zig does not use malloc for its ASTs, as far as I know. It uses lists and indices. I haven't literally read the code lately myself, but I would be surprised if they went back to malloc'ing individual nodes.

Does cve-rs break any type system rules?

Yes.

If so, why hasn't it been fixed yet?

Pretty classic software engineering reasons.

The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sense, instead of putting in a ton of work that will be thrown away.

Other, more serious miscompilations get fixed faster. In fact, a version of the Rust compiler was released today to fix one, even https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/

This one was impacting actual users, and did not require re-writing entire subsystems to fix properly. So the engineering and product tradeoffs are different.

It really depends. For example, it might mean that you do not know the way to do the same thing, but in a safe manner. It might mean that you could refactor your code to do things more safely.

Of course, reasonable people may also believe that it is easier to use an unsafe language directly rather than change the ways that you code.

In my experience doing embedded, operating systems work, compiler work, and others, you never need a large amount of unsafe code. 1%/4% is really about it.

the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you".

It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed.

it also has the gaping type system holes demonstrated in cve-rs

This is not a "gaping hole". It is a compiler bug, which has never been found in the wild.

there are other bugs which occur in Rust

This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.

Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk.

The simplest solution to these problems, if you have the capital, is to buy them.

It's also important to note that Rust as a language does not know about the heap at all, it is purely a library concern. This means that "doesn't include support for custom memory allocation patterns" is purely talking about standard library data structures, and if you need a ton of performance, you're probably going to be writing your own anyway.

It will be nice when the Allocator trait stabilizes so that the ecosystem can coordinate on making this stuff pluggable, but that's not a direct blocker for getting things done if you need to do things today.

The article links to https://www.roc-lang.org/faq#self-hosted-compiler to discuss this.

Memory safety is:

1. Foundational for other forms of safety

2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective.

That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.

For whatever it's worth, I share some of your async-graphql woes, though I haven't investigated things deeply enough to have strong opinions about what to do instead.

Claude Code uses bun.

Depending on how you search specifically, you may or may not get all of them. For example, if you searched for "at protocol" specifically, you wouldn't get comments that are like "I thought we were talking about the old modem protocol!" and similar.

Anyway I don't think that it means that atproto was misnamed or anything, just that this thread isn't the only time people have brought this up.

It's the whole system that is either safe or not, not the individual components.

This is a core perspective disagreement. While this is true:

If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.

That does not mean that increasing the amount of safety in the individual components isn't helpful, because it helps minimize the above outcome, even if it will never be zero.

Cool, I'm not sure that people know that we know each other and have some deeper mutual understanding. :)

although of course that wouldn't work for running tests.

Why not? Unless you mean in the cross-compilation case, in which yeah, to run the compiled tests you'd need an emulator.

in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them.

It doesn't have to be Cargo, but yes, rustc produces executables for the tests, and you have to then run them.

there's the same opportunity for end user memory being corrupted (due to miscompilation)

I agree for sure that the safety of the outputted binary is completely distinct from the safety of the compiler itself.

I think the reason that this framing specifically (in the post and in this comment) strikes me as odd is that "requires unsafe code" sort of implies that you need to use unsafe to fix the unsafety of the outputted binary. That just isn't the case. Of course, this is a serious bug that needs to be fixed, but there's just something about "doing memory unsafe things" in this area that like, I think can be a little mis-leading, even if that's not intentional. But I am going to sit with this and think about it, regardless, because I am not sure that my gut reaction here is completely accurate.

(And, hilariously, looking over some work my agents did on my compiler last night, they fixed some mis-compilations that occurred, entirely in safe code. I bet that's also part of why I'm in this headspace at the moment, it's not like those fixes required dropping down into unsafe to fix either!)

I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think.

It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.

OCaml has often historically been considered a language that's been appropriate to write systems tooling like compilers, runtimes, and unikernels in, even though GC'd languages were/are not often considered for such projects.

The Rust re-write happened before I got involved. If pcwalton is around and sees this comment, maybe he can provide a more first-class account.

Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?

From what I remember, it was a whole-sale re-write from scratch, not a transliteration. While Rust took a lot of inspiration from OCaml, especially in those days, it was different enough that I'm not sure that a more direct transliteration would have been particularly possible, though again, see above, I wasn't there, so I don't know for sure.

I do think it reflects different priorities, but one of those differences is that from my perspective, safety and performance are not inherently at odds. Yes, sometimes it is needed, but not as much as some people seem to think. Sometimes, it also means writing code in ways that communicate things to the compiler that you may not think of if you're not used to thinking in this manner.

A lot of the ways in which the zig compiler works doesn't use pointers, it uses indices. This stuff is easier to write as safe code, not less easy.

Roc is attempting to make a similar set of trade-offs in their compiler as Zig, so it makes sense that the author finds many shared patterns.

I do think that that makes sense, but it also doesn't mean that they have to. I am doing a compiler project that takes a lot of inspiration from Zig (as my language currently inherits some major things from Zig, and I also care a lot about compiler performance) and it's written in Rust, and does not use much unsafe code (outside of the usual suspects of FFI in the runtime, etc).

I am disappointed you're downvoted, Richard. This is a fine reply, and I hope you know that a minor quibble with a single line in the post doesn't mean that I think it's a bad one overall. (EDIT: a few minutes later, the parent comment is no longer grey.)

I also think it's a good thing that you wrote the post in general, when I saw it pop up I was like "oh, of course, this post should exist!" I'm surprised I didn't think about it earlier.

evaluating userspace code at compile time

Usually this would be done via an interpreter, so I'm not sure that it really requires unsafe either. If you are literally executing machine code, sure, but const fn in Rust and constexpr in C++ and many other languages do not do that, as it causes a number of problems (for example, cross-compilation).

probably be a linker

I don't think that's any different either. The core job of linking isn't particularly unsafe.

(Unless, similarly, you're doing the hot reloading stuff)

I do think that is a good point, it's just not what the line actually says. But that's why I wasn't saying "zomg this is WRONG!!!!" but instead, trying to point out that there are subtleties here. For people who aren't as deep in the weeds in this subject, I think the details matter. But again, as I said, I like the post, this is just one thing.

I am also probably in a more pedantic mindset because, well, I'm writing a compiler in Rust, and the words as written do not resonate with me at all.

a perfectly safe compiler that generates vulnerable binaries isn't that much better.

I do think it's much better. Eliminating classes of bugs in one component is a good thing, even if it's not every component. This is a core lesson of Rust! unsafe still exists, but going from "I don't know what is unsafe" to "only this part is unsafe" is a major improvement.

It is an incredibly common comment to be made on posts about atproto, so there certainly are a lot of people here for whom it was a thing.

Rust moved away from OCaml when it decided to be re-written in Rust. The post alludes to this as being a usual time for a wholesale re-write, and I'd agree.

I think this is a fine post. But one comment:

remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job

I don't really think that this is true, in the way that it's written.

I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe.

Does the IETF register trademarks on behalf of their working groups? It’s possible that I’m just misinformed about that.

I left this comment shortly before bed and my thought process was “a working group isn’t a legal entity and therefore can’t do this” but it’s entirely possible that that was shortsighted of me.

(Obviously the IETF itself can.)

There is an IETF Working Group these days https://atproto.com/blog/kicking-off-the-atp-working-group

Those can't register trademarks, of course.

that also runs the only viable instance?

This is false, both in the framing ("instances") and in the viability of running alternative infrastructure.