← Back to context

Comment by muvlon

3 days ago

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

9 comments

muvlon

Reply
rowanG077  3 days ago

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

  • Animats  3 days ago

    The important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as

       for foo in bartab {}

    can usually hoist checks out of inner loops almost for free.

    I used to argue with the C++ committee about to when it's OK to catch an error early. If you write

        #define LEN 1000
    int tab[LEN];
    for (auto p = tab; p++; p <= LEN) { *p = 0; }

    that's a buffer overflow. The question is, is the compiler allowed to generate checking code which will abort the program before entering the loop? Or does it have to execute all the iterations up to the subscript error?

    I argued that it's legit to catch an error at the point it becomes inevitable. This leads to bikeshedding objections: "But what if a signal interrupts the loop before it runs off the end". That's why you need a language where undefined behavior has been nailed down to do this optimization properly.

    • inigyou  2 days ago 

          #define LEN 1000
    int tab[LEN];
    for (auto p = tab; p++; p <= tab+LEN) { if(*p == 42) foo(); *p = 0; }

      Not shown in frame: foo() calls exit(0) and tab always contains a 42.

      The current standard allows the compiler to hoist unsafety only if there's no possibility of I/O or volatile memory access. This is the reason for the rule that infinite loops without the above are undefined behavior - it allows the compiler to merge two loops, the second of which might crash and the first of which can't be proven to terminate.

      1 reply →

  • ssokolow  3 days ago

    True... but if you go by what you're most likely to encounter, I'd argue the biggest unaddressed flaw in Rust is the lack of a current, maintained analogue to tools like Rustig! and findpanics, which would analyze your compiled, optimized binary and report any code paths which lead to panics.

    I don't like having to contort my code to fit each unit of work into the API of `std::panic::catch_unwind` so I can responsibily distrust the transitive dependencies beyond the reach of my Clippy lints.

  • antonvs  3 days ago

    If you really believed that, you’d be programming in something like ATS, Idris, or Spark Ada. The reason that (I’m guessing) you don’t is that it takes a lot more effort to write general purpose code in those languages.

    Rust is pretty much state of the art in this area for general-purpose, non-GC programming languages, and people still complain about the effort involved in writing memory-safe code with it.

    If you really want complete memory safety, use a garbage collected language.

    • rowanG077  2 days ago

      I program mostly in Rust, Haskell and Python nowadays. I indeed would love to go gc-less dependently typed. But I work in a team where the code I build is expected to be maintained by other devs. And going that route is unfortunately not tenable.

    • pjmlp  2 days ago

      Additionally, there are plenty of garbage collected languages with support for doing low level stuff, or RAII, when it is really required.