Comment by tialaramex

Comment by tialaramex 2 days ago

And do you say that C offers these guarantees ?

Real world C software does not read like software written by people who are in fact upholding those guarantees you say C could equally have. It reads as though they think such a guarantee is a joke or an irrelevance. It's not rare for me to run into people who think C's pointers are just indexing into a massive array of all RAM (or its equivalent on today's systems with virtual addressing), that's not just not in the same ballpark as a safe C program, that's playing a different sport on another continent.

foldr 2 days ago

You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language.

>And do you say that C offers these guarantees ?

No, that would be silly, and it's an illustration of why it is silly to say that a language guarantees X if it is the programmer who must check that X holds. If we go down that route (which, to repeat, would be silly), then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants. When you say that "Rust makes the same guarantees regardless of the unsafe keyword", it seems to me that you are doing something equally pointless.

Reply View 12 replies

tialaramex 2 days ago

> You seem to be suggesting that a language being safe or unsafe is a social contract rather than a technical property of the language.
Quite some way up this thread pizlonator insists that each programming language defines memory safety differently, quantifying some as "weaker" or "stronger" and giving the example that Rust has the `unsafe` keyword and so that's weaker than Fil-C.
That's what we were discussing when you jumped in with your C hypothetical.
You apparently instead believe in a single universal "safety" and every language is either absolutely safe or unsafe according to foldr for whatever that's worth - but that's not what we were talking about.

Reply View | 5 replies
- foldr a day ago
  
  No, I just think that Rust is less safe than it would be if it didn’t have the unsafe escape hatch.
  I think you’re taking issue with how pizlonator phrased his post rather than addressing the substance of his point that Fil-C does not have the ‘unsafe’ escape hatch and is therefore safer in this respect. Sure, Rust uses a pretty standard definition of memory safety when talking about the desired property of the program, but pizlonator is talking about the definition of memory safety that the Rust compiler actually guarantees that Rust code will meet, which (when you include unsafe-marked code) is a conditional and weaker one.
  
  Reply View | 4 replies
  
  tialaramex 21 hours ago
  
  I still can't agree with weaker. Yes, it's conditional on the unsafe code actually obeying the rules, and on the tooling, but Fil-C has the same situation, there will be bugs in the compiler, indeed in some cases the same bugs because LLVM has plenty of bugs.
  Crucially unsafe Rust doesn't have weaker rules, it has the same rules, that's my whole thrust here. The change is that the burden of obeying those rules is on you, the programmer, and that's a heavy burden. But it is very much possible for skilled practitioners to carefully achieve that. It's very similar skill to writing C++ stdlib implementations. Aria's "Pre-pooping your pants" essay is colourful but ultimately it's the same sort of thing strong exception guarantees are made of in C++. We go in eyes open, expecting the worst so that we're pleasantly surprised when it doesn't happen.
  It's not practical for humans to write code like this all day, everyday, they make too many mistakes that's the problem in C or C++ - but, seems like it is practical for some skilled people, sometimes, with the benefit of oversight from similarly skilled peers.
  If that isn't enough for you I have good news and I have bad news. The bad news is that for general purpose software too bad, we've known since the middle of last century that we can't do better than this. Fil-C isn't magic, nor are Java and C#. At runtime we detect we can no longer assure correct operation and we abort, this might not be OK, but we can't do better.
  The good news is that we can do better if we're willing to sacrifice generality. The difficulties all come from the fact that ultimately if we're a general purpose programming language we can be made into a Gödel number and then obliged to perform computations on ourselves and we're toast. But we can invent useful languages which aren't powerful enough to do that. Want to decompress ZIP files? No generality needed. Crop some JPEGs? Not needed. Validate whether these graphs are isomorphic? Ditto.
  Rust is a general purpose language, but you might well not need one for your problem, and I say we should prefer not to use a general purpose language when we don't need one.
  
  Reply View | 3 replies
bit1993 2 days ago

> ... then we can make C safe without any technical changes just by adding some language to the standard saying that C programmers are obliged to ensure that their code maintains a certain list of invariants.
In Rust you can use #![forbid(unsafe_code)] to totally forbid unsafe code in your codebase. Rust also checks for memory safety at compile time, these are strong guarantees that ensure that if the code compiles it is memory safe.

Reply View | 5 replies
- foldr 2 days ago
  
  I'm aware of that, but I'm responding to the original claim that "Rust makes the same guarantees regardless of the unsafe keyword" (see https://news.ycombinator.com/item?id=46262774)
  
  Reply View | 4 replies
  
  bit1993 2 days ago
  
  Ah. I agree with you. When unsafe is used the borrow checker cannot check for memory safety, the programmer has to provide the guarantees by making sure their code does not violate memory safety, similar to programming in C.
  But unsafe Rust is still far better than C because the unsafe keyword is visible and one can grep it and audit the unsafe parts. Idiomatic Rust also requires that the programmer provides comments as to why that part is unsafe.
  
  Reply View | 3 replies