Mond_ 13 hours ago

? Putting a program into a safe container or isolation boundary (this is roughly what GC is in this context) causes it to be memory safe. This is not an interesting observation. It also causes it to be significantly slower, to the point of not being competitive anymore.

Ar-Curunir 2 days ago

It is well known that GC allows you to solve memory safety problems

timeon 2 days ago

> proper compiler

Not just compiler but GC as sell. So it does note solve same problem as Rust.

  • levodelellis 2 days ago

    Would you rather have a gc or unsafe?

    In just about every language I seen people use .clone rather than deal with problems so I suspect a lot of cases a GC can be just fine or faster. Although I'm comfortable with memory management and rather use C or C++ if I'm writing fast code

    • timeon a day ago

      > Would you rather have a gc or unsafe?

      Like in case where you can't use Rust? (ie.: existing codebase). Sure that is what Fil-C is good for. Point is that Fil-C does not solve the problem Rust does. It is more like band-aid. (Maybe my comment was misunderstood because of typo: sell/well)

      Also I think there is huge difference between GC and fact that some people use .clone() somewhere.

      • levodelellis a day ago

        Your reply is so ridiculous. I don't think I ever seen a single rust codebase that didn't use unsafe in it or any of it dependencies. People use a lot of clone, it's not just "some" people. Even if we ignore all the webdev writing rust

uecker 2 days ago

The memory model of C is intentionally designed to allow safe implementations (still from the time of hardware-segmented methods).

  • CoastalCoder 2 days ago

    Could you expand on that?

    • aw1621107 2 days ago

      I believe the claim is that there's nothing in the C standard that requires implementations to be unsafe. If they wanted to, they could bounds check pointers, check allocations are still alive when pointers are dereferenced, etc. and still be conformant to the standard.

      • pornel a day ago

        Nothing in the C standard requires bytes to have 8 bits either.

        There's a massive gap between what C allows, and what real C codebases can tolerate.

        In practice, you don't have room to store lengths along pointers without disturbing sizeof and pointer<>integer casts. Fil-C and ASAN need to smuggle that information out of band.

      • uecker a day ago

        Even more, certain rules are specifically designed to make such checks possible while being conformant to the standard.