Aria Desires

@chandlerc@hachyderm.io the api correctness issues i’m thinking of were never an optimization thing, and were always just “the compiler let code compile that was a blatant use-after-free” (on my phone and going off memory, can elaborate more on any of these if you want more details) * pre-1.0 the rust compiler did not require you to specify the (co/in)variance of a type parameter, and if you declared a type parameter but failed to use it in the definition it actually defaulted to *bivariance* which is literally always incorrect. This resulted in some type like Iter<‘a, T>(*const T) basically functioning as if it had no lifetime, oops! This class of bug was eliminated with the introduction of PhantomData (the RFC discusses it). * Rust has obscure support for letting pointers temporary dangle during destructors. You can make a (Box, Vec<&Box>) and make one point at the other, and rust won’t complain about the fact that the Vec definitely contains a dangling pointer when its destructor runs. The argument for this being ok is based on Vec’s Drop being parametric (it cannot observe that T is a reference), and this feature is used by rustc devs to do stuff with Arena allocators. “parametric drop” used to be safely inferred by the compiler but it was so buggy and complicated that it was eventually turned into an unsafe opt-in (see the “dropcheck eyepatch” RFC(s)). * The typechecker people have like 1000 war stories around the compiler failing to correctly handle corner cases of the type-erasure stuff you briefly discuss, especially around what lifetimes associated-types should be required to satisfy (not my area of expertese) * The compiler safely infers Send and Sync for ~every type, and the fact that this actually works great in practice is actually shocking to me whenever I think about it, but the secret sauce is that if your type contains *const T, *mut T, or UnsafeCell your type is opted out of this and you must manually unsafe-impl Send and Sync to opt back in (also *mut T makes you invariant in T as a secret bonus controversial safety guard). The fact that we have different types for “normal pointers” and “pointers unsafe code uses” is actually a really important sentinel for forcing the compiler to apply more conservative ~inference. “here there be dragons”. (probably the OIBIT RFC is the source on this)

@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”!

@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!)

@slava@mathstodon.xyz @zwarich@hachyderm.io @joe@f.duriansoftware.com common rust W making pointer-based graphs too hard to use so you have to use ids

function subtyping is easy, just remember

you use **contra**ceptives when putting it inside and a **co**pay when taking it out

@apmasell@mastodon.social never heard of bool, my only friend is Literal['False']

@mindpersephone@spookygirl.boo it naturally happens constantly in the typesystem, they've gotta deal with it anyway

complex is complex | float | int

:)

anyway just learned python typing invented a new kind of voldemort type -- one which when named doesn't actually name it

`float` and `int` are two distinct types in the type system

but if you write `x: float` that actually means `x: float | int`. but if you write `x: float | int` that means `x: float | int | int`.

anyway that's why `ty` has a `JustFloat` extension that is an actual alias for actual `float` that doesn't expand to `float | int`, so you can actual refer to... just float

https://play.ty.dev/a8714369-9b4c-4028-9418-26727b546205

it makes absolute intuitive sense that all your memory safety bugs would be uniformly distributed throughout your code but if your codebase is like that it should be declared a superfund site and quarantined from the public because that means you have hundreds of ancient buffer overflows that never get fixed

periodic reminder that

"but we have so much old code, surely adding more analyzers to catch bugs in all the old code is much higher impact than piecemeal writing new code in a memory-safe language"

has been repeatedly demonstrated to be a falsehood by the android team

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

@foone@digipres.club i think you might be cargo-mommy's biggest supporter lmao. i really should do a new release or add someone else as owner at this rate.