Comment by tialaramex

Comment by tialaramex 2 days ago

5 replies

View on Hacker News

> 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.

foldr 2 days 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 a day 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
    • foldr a day ago

      I don't think it makes sense to compare non-invariant-respecting unsafe blocks to compiler bugs. It would make sense to do so if unsafe blocks were only present in a highly-verified Rust stdlib, but we both know that's not the case.

      >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.

      Now we're circling back to my argument about C. The C standards committee could declare that 'unsafe C' (i.e. all C) has these very same rules (which C programmers have the heavy burden of obeying). Would this instantly convert C into a memory safe language? Of course not! It's an empty semantic gesture. Similarly, merely saying "Rust programmers are obliged to respect the following invariants inside unsafe blocks!" does nothing to actually decrease the risks associated with unsafe blocks (leaving aside whatever exhortive success such admonitions might have).

      What next, if we accept this logic? Is Perl a language with strict static typing, but "the burden of checking the types falls on you, the programmer"?.

      Reply View 2 replies
      • tialaramex 13 hours ago

        > Would this instantly convert C into a memory safe language?

        I actually strongly encourage finishing this thought. Imagine you're WG14 and you're intending to drop this "safe C" bombshell in C29 and think about the implications just for your document.

        You "just" need to spell out all these rules for the language itself, Rust only has a handful but you've got pages of these, and then you need to go re-design all your APIs so that instead of basically YOLO† each of the standard library APIs has an explicable set of safety requirements, just as Rust has to do with its relatively small subset of unsafe APIs.

        A subset of this work is already underway for WG14 and has been for a few years. You'll need to hurry them along to prepare for your epoch making announcement because they're not expecting to be anywhere close by 2029 but hey, shoot for the stars right?

        At the end of this, you've announced a deeply incompatible C version and the benefit is that if your customers can hire people who don't make mistakes and they port all their C to this new version, it has similar properties to if they were to rewrite it in Rust. Don't expect applause, in fact, I'd recommend hiring bodyguards.

        † I think people really underestimate how much C relies on this. Remember C provides qsort, an unstable type-erased comparison sort (hopefully an introsort, but in some implementations literally just Hoare's Quicksort which is significantly older than C itself) which has arbitrary Undefined Behaviour if you screwed up your comparison function and yet for all the popular implementations it's still slower than in Rust which doesn't have that UB problem at all.

        So now you're documenting specifically for functions like this why "safe C" is both much harder to use and slower in your standards document like it's an achievement, and unlike Karoline Leavitt you're not even getting paid to do this. Maybe you should take up knitting instead?

        Reply View 1 reply
        • foldr 13 hours ago

          You’ve kindly finished the thought for me. You now have a “safe” version of C purely by updating the standard and associated documentation. (It’s not actually true that you need to redesign all the APIs in the stdlib. You just need to document the appropriate restrictions on how they may safely be used, just as you would have to do with a Rust function marked ‘unsafe’. It’s trivially possible to write an unsafe-marked Rust function that’s guaranteed to be memory safe if and only if an arbitrary invariant is maintained.)

          In reality of course, this is all absurd. No matter how much or how little work it turns out to be, writing reams of standardese and leaving actual C implementations untouched would do nothing to reduce the safety risks associated with C code.

          By the way, you’re wasting some energy arguing points that I agree with (e.g. that Rust has a better sorting API than C). My comments here are not anti-Rust. I merely disagree with the claim that Rust code marked ‘unsafe’ is as safe as regular Rust code.

          Reply View 0 replies