[rowanG077]

Something that is important to me is that it's caught at compile time. A memory issue is a logic bug. Fil-c simply moves that from undefined behavior/security issue/incorrectness to a crash. That's better than what it was. But I generally don't want my programs to crash. Having memory safety at compile time is much more worthwhile imo.

[wat10000]

It’s the exact opposite for me. Catching it at compile time is great, but the most important thing by far is that it’s caught somewhere instead of creating a security issue.

[muvlon]

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.

[rowanG077]

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

[Animats]

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]

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

[Animats]

Right, tab+LEN. The intended error was "<=" instead of "<".

[ssokolow]

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]

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]

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]

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