graydon

graydon , 1 day ago

@whitequark there are three hard things in computer science, and between two and five of them are known to appear in a target triple.

graydon OP , 2 months ago

@zwarich @uep oh yeah the bug's particulars seem odd in their own right. I just mean like .. people write bugs, y'know? in languages. "this can't happen" is an easy thing to be wrong about somewhere.

graydon OP , 2 months ago

(like y'all remember java has NPE right? null pointer exception? java is memory safe. it's great. java or C# with null split out into its own type like option so you can mostly statically exclude it is even better. we're just trying to get systems programmers to that point. the crash is the good case. the bad case is "someone takes over your computer". that's why Fil-C was describing itself correctly as a memory-safety system last week. because it turns all the bad cases into crashes. the crash is the good case.)

graydon OP , 2 months ago

(this seems to be getting fresher by the day, I guess the more people use rust in production the more that'll be clear? there are lots of ways to make most programs in most languages -- memory safe languages! -- halt with a fatal error. we know this right? we do not write in total languages with functional correctness proofs. like basically anyone at all. it'd be great if we did but the set of people who get paid to do that is extremely small and they produce code at a rate that would make your manager fall out of their chair laughing. because it is extremely super duper hard. that was 100% not the target niche rust was aiming for.)

graydon OP , 3 months ago

@josh @matt well, "numeric" libraries are usually floating point.

there are libraries with hot integer loops (crypto, codecs, hashing, parsing, serialization) but these are libraries that already do lots of micro-optimization and benchmarking and pay attention to their bit-twiddling -- they'll have no problem just picking the wrapping ops when checked ones show up in profiles.

the rest of the time, in non-inner-loop code, IME integer math is mostly like either harmless user-config-value stuff or else "a few numbers multiplied together and then passed to an allocator or bulk-copy unsafe function" and that latter one is the problem. attacker can make one of the terms a little bigger than you expected => uh oh.

graydon OP , 3 months ago

@matt and also like .. gosh .. I really wish we could all at least agree collectively that a little perf overhead is worth it for meaningful safety. I wish rust had shipped more (eg. checked arithmetic by default).

sadly people keep shipping new PLs that trade the other way. zig, hare, odin, jai -- fine languages! -- but whoops we're back to pervasive memory errors. I guess it'll depend if anyone is actually willing to pay the dynamic checking cost or if it just turns into a rhetorical thing ("our code can be safe! but ugh so slow so we will turn it off in prod")

like I really truly want the speed limit on my town's streets limited to 30km/h you know? and I would 100% buy a cell phone that said "this can't be taken over via memory bugs" even if it's noticeably slower. I bet a lot of people would. safety features are good!

graydon OP , 3 months ago

@matt yeah I mean the fundamental issue to me is just that on even the most aggressive RIIR timeline I can imagine (which is not exactly forthcoming!) we've got decades ahead of us of unix, windows and macos/ios userspaces that are otherwise going to be deployed and vulnerable. plus vast, vast amounts of in-house and embedded code. and a lot of legacy code is of the form "nobody alive knows exactly what it does or how it works" so even rewriting is deep archaeology and behaviour-regression.

graydon OP , 3 months ago

@matt yeah, I mean, I can understand both of those aspects to a moderate extent but .. I guess to me it seems like universal adoption of any language just isn't plausible, and also isn't necessary to get you over the hump of good-enough network effects and the local zero-sum-ness of making per-project PL choices (after all rust is at 2% now and plenty of projects choose it!)

the question is: should the 98% of people who don't choose it, or the 20%ish of all new code that's C/C++, or the 99.99%-of-all-code that's existing already-written codebases, have some other options to help their computers not get taken over? or should they just be punished until they make the right choice? to me this has a fairly obvious answer.

graydon , 4 months ago

@zwarich I think it's nice to be able to move declarations around in a file or among files without changing meaning. and I think it's broadly annoying to force people to topo-sort their declarations and/or definitions (especially if they're mutually recursive). I guess if you have forward declaration for everything, and (more importantly) if you can only ever define a decl once, I suppose it's not so bad. but a lot of PLs fall down on one or another of those.

graydon OP , 6 months ago

@joe uh .. I guess .. when we switch to indirect references like maybe a helpful aspect of that hypothetical arena-oriented systems language? or an ECS? just spitballing.

graydon , 6 months ago

@joe @zwarich a fair observation. I always try to emphasize the multiple goals served by the ownership structure, not just memory safety. but there are a lot of really obnoxious design edge cases that just go away if you have coarse intra-program boundaries you can safely and cheaply roll back to (not least: how you handle errors -- cf. rust's panic-handling muddle)

graydon , 6 months ago

@zwarich @joe yeah every napkin-sketch design for "another damn systems language" I have in my drawer starts with "arenas for everything" and works backwards from there.

graydon , 7 months ago

@chrisamaphone yes lots of people view it as a chore and don't find any of the alternatives fun either -- they are just boring and painful scheduled blocks of suffering, done for health or beauty (hence all the listening to podcasts / watching TV while exercising).

most other supposedly-more-fun forms are also (variously): expensive, outdoors (so weather dependent), dangerous, embarrassing, require coordinating with a buddy or a team, take a long time, require training, require special equipment, or require large specialized spaces set up so are rare.

the modern semi-standardized gym also isn't just weights: it's cardio machines (rowing/cycling/ellipticals/treadmills), bodyweight and calisthenics mats/bars/anchor points, free weights and weight machines. it's a 24/7 DIY salad bar of cheap, simple/no-instruction, compact devices to get your annoying chore done as quickly as possible (like ~30min). often just like in an otherwise-unrented office space (so ubiquitous).

graydon , 8 months ago

@mcc (put differently: if you're in a PL where all fields / variables that store pointers point to the first word of a well behaved heap cell -- a uniform representation language -- you can do much, much easier stuff! but you leave a lot of performance on the table if you are always chasing pointers and exploding nested structures into separate allocations. there is a little bit of design room between -- eg. treat unions as special containers or whatever -- but we didn't land there. we did try a lot! rust was originally a copy-on-write language, like newsqueak .. or I guess early swift! people forget a lot :)

graydon , 8 months ago

@mcc the bug that is tricky to prevent is this:

enum U {
Int(i64),
Ptr(Box<i64>)
}

let mut x = U::Ptr(Box::new(10));
match x {
U::Ptr(ref b) {
x = U::Int(1234); // clobber ptr
println!("{}", b); // derefs 1234
}
}

because rust is a non-uniform-representation language, and one that lets you take pointers into the middle of things, and even lets you change the size of things you're pointing into the middle of, you have to prevent mutation while such references are outstanding if you want to ensure type safety and thereby memory safety.

you can construct something similar / less-contrived-seeming with iterator invalidation though it's easier to do workarounds like copy-on-write since the resized vec is already on the heap:

let mut x = vec![1,2,3,4];
for i in x {
x.push(1); // might resize x
println!("{}", i); // use after free
}

if you read through early design notes on rust and the borrow checking rules, you'll see reference to "dan's bug" which is the former change-the-variant-of-a-referenced-enum-thereby-breaking-type-safety bug, and is directly what led to the current rules.