Rust – Compile Time Memory Safety

[amalcon]

The author says that this is "why Rust is interesting". I've done a little bit with Rust -- no production code, but some simulations and things like that. While compile time memory safety was the first thing to interest me in Rust, I don't even think it's the primary selling point anymore. The selling point to me is that nearly everything behaves in predictable ways.

E.g. since immutable references are the default, you immediately know whether or not a call will modify its argument. E.g. the existence of traits and compiler warnings for style mean that method naming conventions are incentivized, because implementing a trait usually gives you a lot for free. Even performance characteristics are very predictable, a statement which I can only otherwise make about C and assembly (and those are not predictable at all in other ways).

Yes, the memory safety does play into this. It's much more than that, though: memory safety is just one factor in a kind of pervasive predictability that the language encourages through its very design.

[estebank]

The biggest selling point for Rust is a non-obvious one and one that is hard to "sell" with screenshots: refactoring. Despite having few tools for automatic refactoring, manual refactoring of large Rust codebases is a breeze: change the portion of code you care about, follow the compiler's complaints and by the end you're likely to have a codebase in a good state. I wouldn't be able to go back to a dynamic language after using Rust for so long, I'd be in constant panic about changing the smallest thing. I equate it to the same discomfort I feel when getting on a car with no seatbelts. I'm just waiting on the day when I can plug the change I want to do to rustfix and let it figure it out, with the help from the compiler.

[cttet]

Actually I got into rust because it is the only language that has both ADT/patten matching and a practical mindset/community. There is simply no alternative. I would even code front-end rust for the sake of this.

[microtonal]

E.g. since immutable references are the default, you immediately know whether or not a call will modify its argument.

You do not, since the type of which an object is referenced could use interior mutability (e.g. RefCell). So, you only know if this is the case after inspecting the type.

Of course, the default in Rust is to use exterior mutability and in general, interior mutability is/should be avoided.

(I agree with the general thrust of your comment though.)

[kkimdev]

I fully agree with you, and actually I want to write a summary of those less-discussed features that have high productivity impact including the predictability you mentioned in the future.

Though, for the people who haven't explored Rust yet, I still think that focusing on the memory safety, the most powerful feature, is a good approach. Personally I tried explaining other smaller benefits first, e.g., immutable by default, move by default, no header files, but didn't work well as I thought. Exploring another language is a significant investment, and people need a significant reason (at least those that appear to be at first glance).

[steveklabnik]

I agree with you, for sure. We had a huge community discussion about this in 2016: https://brson.github.io/fireflowers/

[leshow]

Rust has a great type system that enables the kinds of things you're talking about. It's like c++ and haskell came together and had a baby.

[millstone]

> Rust enforces single mutable ownership or multiple readonly aliases at a time. In fact, they are very good idioms to structure large codebase anyways, and normally they do not get in the way for ordinary applications.

No these limitations routinely get in the way for ordinary applications. The borrow checker is a source of frustration when ramping. Back-references get smuggled in as array indexes. Prohibiting global variables is tough. Any sort of app that can't be structured as a tree is going to have pain.

This safety is really valuable, but let's not pretend it comes for free.

[0815test]

The author is somewhat mistaken there - what Rust actually enforces is a clear alternative of exclusive ownership/borrowing, or shared access with multiple aliases being active at the same time. While these are normally identified with "mutable" vs. "readonly" access, this is not true in some cases, where special structures with "interior mutability" can be provided with different behavior. For example, if you need to share writable access to a piece of data, you can use the "Cell<>" or "RefCell<>" generic types. For an object which needs to have multiple "owners", each of which can extend its lifetime and prevent the object from being freed, there is the Rc<> type, etc. This stuff may not come for free, but quite often its cost can be made very reasonable while preserving desirable safety properties.

[pornel]

To me it was the opposite: it gave me a vocabulary and taught me how to think about these problems.

Shared mutable state and ownership exists in C, but I just don't get any compiler support for it. I can't even document it in code, so I (and users of my libraries) rely on RTFM.

In C I'd just "wing it", and tweak the code until it stops crashing. Maybe add a flag with "obj.free_data_ptr = true" and keep adding mutexes or copies of data where I suspect it's necessary.

In Rust I get predefined templates for this — owns & borrows, cells/atomics, refcouted and mutex containers, etc. The compiler says "nope, this is wrong!" and I get to conciously decide how to solve it — do I share or copy the data? Is the sharing dynamic, or just in a wrong scope? And my decisions are documented in code, and enforced by the compiler.

[foota]

Isn't the example with re-using a moved c++ vector completely safe?

    std::vector<int> x = {1, 2, 3};
    process(std::move(x));
    x.push_back(4);
    // Runtime invalid memory access

[kkimdev]

Oh, I didn't know about this one. I did some search, and looks like it should be "valid but unspecified state" after move?

I can't think of any case that relying on unspecified state is desirable even if it's valid, though I guess it's better if I change that to x.pop_back(); to be clear.

Please let me know if my understanding is incorrect and thanks for the information!

[marcianx]

Yes, it's completely safe and its rust equivalent is

    let x = vec![1, 2, 3];
    process(std::mem::replace(&mut x, Vec::new()));
    x.push(4);

https://doc.rust-lang.org/std/mem/fn.replace.html

[bluejekyll]

It’s runtime safe (I’m taking your word for it). In Rust this would be a compile time error.

Although, are any C++ compilers able to at least issue a warning in this case? It wouldn’t surprise me if they could.

[zelly]

Move constructors are allowed to call the moved object's destructor.

Not necessarily like the example given, but

  Object a {std::move(x)};
  x.push_back(4);

could/should segfault.

[millstone]

Yes it is safe.

[Const-me]

    int x;
    int y = square(x);
    // Passing a garbage value at runtime.

My C++ compiler doesn’t build that:

error C4700: uninitialized local variable 'x' used

[int_19h]

That's because you're compiling with warnings-as-errors.

And even then it's still unable to detect anything but the simplest case. E.g. this compiles with no warnings:

   void foo(int& x) {}

   int x;
   foo(x);
   int y = square(x);

[IshKebab]

This is a really nice way to explain the additional level of safety you get over C++.

[lincpa]

Rust implements safe and efficient programming by simulating bank lending practices. This is the first time in the programming language world to reference financial models at the language level, but unfortunately, Rust language designers are not proficient in financial knowledge and have made mistakes in core fundamental issues. The relationship between borrowing and lending is not a buying and selling relationship. It is caused by the transfer of resource use rights, not the transfer of ownership. It causes a series of semantic errors and cannot fully and correctly refer to the financial system knowledge, making its programming too complicated.

The financial system is the safest, most stable, most rigorous, largest and most tried-and-tested system in human history. From ancient times to today, male, female, old, young, wise, stupid, positive, evil, good, evil, With the participation of the whole people in the game, Rust only learned a little bit of fur and took the wrong knowledge, but he also achieved great success.

Therefore, I suggest that computer science should classify financial knowledge as a compulsory course, which has great reference significance for building a safe, efficient and stable system.

from: https://github.com/linpengcheng/PurefunctionPipelineDataflow...

[int_19h]

The use of terms like "ownership", "borrowing" etc with respect to object lifetime management long predate Rust. You may not like the way they are defined in this field, but it's a well-established definition. And it is not intended to have much to do with "bank lending practices", other than a very rough analogy that's easier to explain.

[ncmncm]

Somebody should tell all the people made homeless by the banking crash of 2008 how uncrashable the banking system is.