6 ms·

What's happened is that you've been poisoned so badly by languages like C that you no longer even understand what's actually going on. Your world becomes a bew

What's happened is that you've been poisoned so badly by languages like C that you no longer even understand what's actually going on. Your world becomes a bewildering mess in which it seems as though nothing can ever be trusted, and so you stumble into either writing endless checks because you're never sure of anything, or you throw your hands in the air and pronounce doing nothing "good enough" then blame others when inevitably your software doesn't work. Take Rust's Allocator::allocate, defined as: fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError>; Yes, our allocation might fail, and in this case our result is Err(AllocError). That's a perfectly good result, and a perfectly good allocation error. It's not the memory you wanted, because your allocation failed, but it's not "invalid" in any useful sense.

jonathanstrange 10mo ago
WTF? I don't even program in C - but I do know Rust (and Ada). Being a little bit less condescending would go a long way if you want to be taken seriously. So much for the tone. To address the content: Yes, you have to deal with that error result just like you have to deal with a nil pointer. No difference. That's the point. By the way, the toxic behavior of the Rust community is one of the reasons why I barely use the language.
- tialaramex 10mo ago
  Even if you don't know C its influence has clearly poisoned your thinking about this issue. The whole point of the billion dollar mistake is that the null pointer isn't actually a pointer, we would not have a type which is "Either a String or, sometimes just for fun the integer 19" because that's silly, so we shouldn't have a type which is "Either a pointer to T or, sometimes just not". The huge difference is that if you don't make this mistake you only have to care about that "it wasn't a pointer" case when it might not be a pointer. Once you've handled that you're done, but with the C-style pointer that Tony's lecture is about you can't tell whether that was done, at every point in the program if you see a pointer maybe it is null. In both Rust and Ada the type system is strong enough to express this. It is very silly to pretend that Err(AllocError) is invalid, it's not invalid at all, maybe that value wasn't what you were hoping for but it's entirely valid.

jonathanstrange 10mo ago

WTF? I don't even program in C - but I do know Rust (and Ada). Being a little bit less condescending would go a long way if you want to be taken seriously. So much for the tone. To address the content: Yes, you have to deal with that error result just like you have to deal with a nil pointer. No difference. That's the point. By the way, the toxic behavior of the Rust community is one of the reasons why I barely use the language.

tialaramex 10mo ago
Even if you don't know C its influence has clearly poisoned your thinking about this issue. The whole point of the billion dollar mistake is that the null pointer isn't actually a pointer, we would not have a type which is "Either a String or, sometimes just for fun the integer 19" because that's silly, so we shouldn't have a type which is "Either a pointer to T or, sometimes just not". The huge difference is that if you don't make this mistake you only have to care about that "it wasn't a pointer" case when it might not be a pointer. Once you've handled that you're done, but with the C-style pointer that Tony's lecture is about you can't tell whether that was done, at every point in the program if you see a pointer maybe it is null. In both Rust and Ada the type system is strong enough to express this. It is very silly to pretend that Err(AllocError) is invalid, it's not invalid at all, maybe that value wasn't what you were hoping for but it's entirely valid.