Post #4333759

2026-07-11 02:26 UTC

@chandlerc@hachyderm.io Only skimmed the slides for now but this feels like it will be brutal to write interfaces for, which unfortunately makes sense if you’re trying to faithfully encode typical c++ interfaces. Y’all have clearly done a lot more homework on this problem at this point than probably anyone, which makes me excited to see where you find the serious friction in this design. As a collections API person my assumption has always been that C++-style iterators (and slices) will be the most painful things to describe and abstract over in any system like this. As an unsafe rust person, I am also worried about the complexity and stakes of writing the signatures of the safe api over the unsafe code — we had a lot of mishaps in rust land back in the day from bad defaults or the compiler not applying some conservative assumption the api author has to opt out of. As a gradual types person I am excited to see where your non-strict mode is forced to make unsound assumptions for the sake of common case ergonomics and usability (no one is without sin here, especially once inheritance is involved!)

Replies (2)

@Gankra@toot.cat 2026-07-11 04:33

@chandlerc@hachyderm.io ok now that i’ve properly watched the talk i have to give huge kudos to josh for being extremely open about the obvious comparisons that anyone would make to rust, while making it to 87/91 minutes before i felt literally any urge to go “now hold on”. not serious and not your fault, a random line just ran into some Historical Political Baggage which is a fun story I now have an excuse to share :p The statement of “unsafe rust is MORE unsafe than c++” was a big talking point for years which slowly transformed from “reasonable question we’d ask ourselves” to “extremely disingenuous talking point you’d get from someone who’s trying to justify dismissing rust wholesale” (to be clear I don’t think you’re doing that at all). So like it’s definitely a legitimate concern that the existence of pervasive high-level assumptions about pointer aliasing and validity could in theory result in rust code being a big ticking time bomb where one small error in unsafe code creates a huge disaster. And certainly we do turn on several fancy noalias optimizations in llvm (although we don’t do TBAA so we’re also less aggressive in some places), and certainly that occasionally goes awry. However over the years the empirical results I’ve observed have been that UB in Rust is often more contained. In particular there’s a high chance of UB quickly causing a panic/abort because there are so many random stray bounds checks and other assertions that it’s hard for execution to go rogue for long. A weird semi-accidental defense in depth. Like for a long time Firefox thought there was some really evil UB in Rust’s HashMap but it turned out that there were just a lot of HashMaps and so any stray memory corruption bug from anywhere in the codebase (i.e. C++) had a pretty good chance of hitting a HashMap… and corrupting memory owned by Rust very quickly resulted in a crash instead of further corruption. So the crash stats were just stuffed to the gills with “oh my god we segfaulted in HashMap”!

Open ##4333760
@chandlerc@hachyderm.io 2026-07-11 04:11

@Gankra@toot.cat First off, awesome thoughts just from the slide skim -- super happy to have this kind of feedback. Regarding writing interfaces -- that's definitely something we're thinking about. Are there specific examples off the top of your head that seem worrisome here? If so, super useful to know, and we can probably work some examples with them to see how it plays out. FWIW, the interfaces we've sketched so far look OK -- not as simple as Rust, but that was never an option. But they seem to be progressive in pulling in complexity, and provide a meaningful generic semantic model. That said, one of our next efforts specifically to build some of the primitives of the standard library in the model, as well as some of the canonical layers on top to evaluate. As I said, if you have thoughts of what might be interesting or hard, happy to try and include them in these. And if they surface problems, we can still change this easily. =] Regarding iterators (and slices) -- the whole system is designed to allow all of these to be abstract in the same way as pointers, and in a consistent way across all three. But definitely, this is going to be a critical thing to see how it plays out. Regarding unsafe code -- our plan is specifically to _not_ allow optimizing based on safety assumptions. That gives up some optimizations, but we largely don't have them in C++ today (what safety assumptions...), and so we think we can survive. If we need an optimization assumption, we'll add that as a separate and distinct unsafe feature so we can be wildly more cautious about it. So the hope is that the soundness bar for unsafe code is generally much lower (at the price of optimizer not leveraging assumptions). And regarding non-strict mode -- again, the hope is that we can lower the soundness bar to roughly that of C++. Which isn't perfect, but seems like an attainable state and a reasonable tradeoff point. We'll still have to see what it plays out as though. =]

Open ##4333762