6 ms·

What I like most about Rust is that I can pass references around without worrying whether the value they reference will continue to exist. This has been a const

What I like most about Rust is that I can pass references around without worrying whether the value they reference will continue to exist. This has been a constant mental burden for me in C++ and has led to some unnecessary defensive copying. I'm not so sure whether Rust's strong immutability/exclusivity guarantees are worth the trouble though. Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context.

supermatt 7y ago
Aren't the strong immutability/exclusivity guarantees specifically the reason you can pass around references without worrying if the referenced value will continue to exist?
- fauigerzigerk 7y ago
  I don't see a reason why that would be the case, but I remain open to be educated ...
  - dbaupp 7y ago
    Without the exclusivity, it would be easy for a reference to be invalidated; the classic example is let nut v: Vec<T> = ...; let r: &T = &v[0]; v.push(...); // A foo(r); // B The reference passed at B might be invalidated by A, if the vector is reallocated. It’s the shared vs exclusive borrowing that defends against this, by flagging the above program as an error.
    - LessDmesg 7y ago
      And this is another point in favor of compacting GCs: non-GC languages are moving things around almost as much (i.e. growable arrays are ubiquitous, plus hashmaps may be based on them too etc). Without a GC the simple task of moving references becomes dangerous and requires the pain demonstrated to us by Rust (or leads to pervasively crashy software culture demonstrated to us by C++). With GC, this type of thing is not something the developer needs to care about.
      - jfkebwjsbx 7y ago
        > pervasively crashy software culture demonstrated to us by C++ Please don’t spread FUD. The majority of commercial C++ software out there is rock solid. Vulnerabilities are the actual problem in today's Internet connected world and why Rust has grown so fast. As for GCs: they are not good enough for some fields, so they cannot be used. Even state of the art ones like Go's.
        zelphirkalt 7y ago
        Why the "commercial"? Are other software types not worthy to be considered in this? Are open source non-commercial projects inherently worse code and more crashy? Should we not look at all kinds of software, when talking about programming languages in general? It has been my experience, that even the well known softwares written in C (not sure about C++) are indeed kind of crashy. Example: Open Broadcast Studio, used by many people to stream on various platforms. It is possible there to go into the settings and change them so that OBS crashes and cannot be restarted again, unless you guess, that the configuration is faulty and OBS is unable to deal with a faulty config. You can only get it to run again by removing the config or reinstalling. Great quality. VLC is another example of such crashy software. Not only did it crash many times in the past, but also cannot properly deal with unplayable files in a looping playlist and will simply bring all your cores to 100% usage. So far some anecdotes from the well known C software world. I am not sure, whether the people in the respective community consider these softwares to be good quality.
        erik_seaberg 7y ago
        Apart from maybe seL4 (which I only know by reputation, and was translated from a formally verified spec) I can't name any software that I would call reliable. If we ever want computers to actually work, the whole stack needs to be flensed down to the metal and replaced, and I hope Rust is the language to do it with.
        littlestymaar 7y ago
        The op is talking about compacting GCs and Go's isn't a compacting one. Go's GC is a variation of a regular mark and sweep GC: the GC starts exploring the heap to find all reachable memory, and then clears the unreachable one, meanwhile compacting GCs move the reachable memory from one place (the “from space”) to another (the “to space”), which become the new heap. Theses two garbage collectors famillies are completely different. BTW, calling go's GC “state of the art” is debatable at best. See : https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=15496e3661e1 https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
    - fauigerzigerk 7y ago
      So the reason why this causes a problem is that mutating an outer value could invalidate the lifetime of an inner value. Could this not be covered by the lifetime guarantee without imposing read/write exclusivity on all values even where lifetimes are unaffected?
      - steveklabnik 7y ago
        It is not clear to me what your question is asking, to be honest.
        fauigerzigerk 7y ago
        The code posted by dbaupp shows how violating Rust's immutability/exclusivity guarantee can also violate the lifetime guarantee. The implication being that the lifetime guarantee depends on the immutability/exclusivity guarantee (as supermatt claimed earlier). It's a good example, but I'm still not enirely convinced that the implication is necessarily correct. I wonder if a sufficiently smart compiler could not detect this particular special case and relax immutability/exclusivity in other cases where no references to the internal structure of a value exist, or if it could even keep whatever r is referencing alive to uphold the lifetime guarantee. I realise the latter could have some undesirable side-effects wrt memory usage and it raises ownership questions if there are multiple such references. It's essentially what persistent data structures in functional languages do and it may not be a good fit for Rust. The reason why I'm even interested in this is that Rust can sometimes feel restrictive in situations where having both mutable and immutable references or more than one mutable reference to the same thing is reasonably safe, such as in the local scope. Obviously people are working around mutability restrictions by using indexes/handles instead of references, but that doesn't seem any safer.
        steveklabnik 7y ago
        There's a few different things at play here: 1. In order a sufficiently smart compiler to understand if this is okay, it would have to know how the Vec<T> type actually works. But Vec<T> is a library type, and uses unsafe code, which is kind of definition-ally code that the compiler cannot understand. So, even for this specific case, it is too hard to do so today. A human cannot even tell if this is okay or not, right now, because you'd need to see the code that's in the `...`. 2. Even if it could, it's unclear if it's a good idea. The more complex analysis a compiler can do, the harder it is to explain what it's doing to end-users. Imagine that, for example, we wrote this code, with the `...` being a case where it's safe, but then we modified it to a case where `...` was not safe anymore. What would that diagnostic look like? How could it be communicated to people in a useful way? 3. There's a tension here. If you make it work for very specific reasons, any small changes would likely cause it to break, whereas it breaking up front may lead you toward a design that is overall more robust. > It's essentially what persistent data structures in functional languages do and it may not be a good fit for Rust. We have those! https://crates.io/crates/im https://crates.io/crates/im > Rust can sometimes feel restrictive in situations where having both mutable and immutable references or more than one mutable reference to the same thing is reasonably safe, such as in the local scope. It depends! You're not wrong, but also see my comment over here: https://news.ycombinator.com/item?id=22466587 https://news.ycombinator.com/item?id=22466587 even local scope may not be enough.
  - deleted 7y ago
    [deleted]
- deleted 7y ago
  [deleted]
- oconnor663 7y ago
  These things are all related, but in my mind this part is more focused on the reference lifetime rules than the reference aliasing rules. As in, even if there's only one reference in the world, we still can't drop() the thing it refers to while the reference exists.
pedrocr 7y ago
> I'm not so sure whether Rust's strong immutability/exclusivity guarantees are worth the trouble though. Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context. For the multi threaded context it's amazing. Compile-time data-race checking is such a unique and useful feature. That and the great ergonomics of the locking primitives makes multi-threaded programming in rust really enjoyable.
- oconnor663 7y ago
  > great ergonomics of the locking primitives I think this is a really underrated benefit of the ownership model. You cannot forget to acquire a lock, and you cannot keep a reference to a lock's contents past the point where you've released it.
pornel 7y ago
> at least not in a single threaded context. That's the beauty of Rust: it assumes single-threaded programs don't exist. All types — including all 3rd party libraries — are forced to be either thread-safe or explicitly not compile if they'd cross thread boundaries. Nobody has "but I don't support multi threaded programs" excuse, so you may as well throw multithreading at everything.
cogman10 7y ago
> Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context. Oh, it has for me. In fact, unexpected mutation has been one of the most difficult bugs I've encountered. I had a method, foo, which when given a NavigableMap (java), it would throw an exception. However, if you called the same method with the same Map, no exception would be thrown (because the map was mutated deep down). Turns out, in the 84th circle of hell after a sub-sub-sub map view was created. A cute little said something like 'if key doesn't exist, associate key with 0'. Because NavigableMap views are mutable in java this eventually made it's way all the way back to the parent map which, consequentially, caused the map to go down a different path when the same method was re-invoked. It took a very long time to ultimately find that mutation due to the complexity of the code.
randyrand 7y ago
Sounds like you should be using shared_ptr! It guarantees to keep the object around.
- fauigerzigerk 7y ago
  If it's my choice to make and it's not performance critical code then I can do that. But in many cases I'm using APIs designed by others. Most older libraries come with their own idiosyncratic memory management patterns. Even the standard library has lots of different ways of passing reference-like things around. E.g. https://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view https://en.cppreference.com/w/cpp/string/basic_string_view/b...

supermatt 7y ago

Aren't the strong immutability/exclusivity guarantees specifically the reason you can pass around references without worrying if the referenced value will continue to exist?

fauigerzigerk 7y ago
I don't see a reason why that would be the case, but I remain open to be educated ...
- dbaupp 7y ago
  Without the exclusivity, it would be easy for a reference to be invalidated; the classic example is let nut v: Vec<T> = ...; let r: &T = &v[0]; v.push(...); // A foo(r); // B The reference passed at B might be invalidated by A, if the vector is reallocated. It’s the shared vs exclusive borrowing that defends against this, by flagging the above program as an error.
  - LessDmesg 7y ago
    And this is another point in favor of compacting GCs: non-GC languages are moving things around almost as much (i.e. growable arrays are ubiquitous, plus hashmaps may be based on them too etc). Without a GC the simple task of moving references becomes dangerous and requires the pain demonstrated to us by Rust (or leads to pervasively crashy software culture demonstrated to us by C++). With GC, this type of thing is not something the developer needs to care about.
    - jfkebwjsbx 7y ago
      > pervasively crashy software culture demonstrated to us by C++ Please don’t spread FUD. The majority of commercial C++ software out there is rock solid. Vulnerabilities are the actual problem in today's Internet connected world and why Rust has grown so fast. As for GCs: they are not good enough for some fields, so they cannot be used. Even state of the art ones like Go's.
      - zelphirkalt 7y ago
        Why the "commercial"? Are other software types not worthy to be considered in this? Are open source non-commercial projects inherently worse code and more crashy? Should we not look at all kinds of software, when talking about programming languages in general? It has been my experience, that even the well known softwares written in C (not sure about C++) are indeed kind of crashy. Example: Open Broadcast Studio, used by many people to stream on various platforms. It is possible there to go into the settings and change them so that OBS crashes and cannot be restarted again, unless you guess, that the configuration is faulty and OBS is unable to deal with a faulty config. You can only get it to run again by removing the config or reinstalling. Great quality. VLC is another example of such crashy software. Not only did it crash many times in the past, but also cannot properly deal with unplayable files in a looping playlist and will simply bring all your cores to 100% usage. So far some anecdotes from the well known C software world. I am not sure, whether the people in the respective community consider these softwares to be good quality.
        erik_seaberg 7y ago
        Apart from maybe seL4 (which I only know by reputation, and was translated from a formally verified spec) I can't name any software that I would call reliable. If we ever want computers to actually work, the whole stack needs to be flensed down to the metal and replaced, and I hope Rust is the language to do it with.
      - littlestymaar 7y ago
        The op is talking about compacting GCs and Go's isn't a compacting one. Go's GC is a variation of a regular mark and sweep GC: the GC starts exploring the heap to find all reachable memory, and then clears the unreachable one, meanwhile compacting GCs move the reachable memory from one place (the “from space”) to another (the “to space”), which become the new heap. Theses two garbage collectors famillies are completely different. BTW, calling go's GC “state of the art” is debatable at best. See : https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=15496e3661e1 https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
  - fauigerzigerk 7y ago
    So the reason why this causes a problem is that mutating an outer value could invalidate the lifetime of an inner value. Could this not be covered by the lifetime guarantee without imposing read/write exclusivity on all values even where lifetimes are unaffected?
    - steveklabnik 7y ago
      It is not clear to me what your question is asking, to be honest.
      - fauigerzigerk 7y ago
        The code posted by dbaupp shows how violating Rust's immutability/exclusivity guarantee can also violate the lifetime guarantee. The implication being that the lifetime guarantee depends on the immutability/exclusivity guarantee (as supermatt claimed earlier). It's a good example, but I'm still not enirely convinced that the implication is necessarily correct. I wonder if a sufficiently smart compiler could not detect this particular special case and relax immutability/exclusivity in other cases where no references to the internal structure of a value exist, or if it could even keep whatever r is referencing alive to uphold the lifetime guarantee. I realise the latter could have some undesirable side-effects wrt memory usage and it raises ownership questions if there are multiple such references. It's essentially what persistent data structures in functional languages do and it may not be a good fit for Rust. The reason why I'm even interested in this is that Rust can sometimes feel restrictive in situations where having both mutable and immutable references or more than one mutable reference to the same thing is reasonably safe, such as in the local scope. Obviously people are working around mutability restrictions by using indexes/handles instead of references, but that doesn't seem any safer.
        steveklabnik 7y ago
        There's a few different things at play here: 1. In order a sufficiently smart compiler to understand if this is okay, it would have to know how the Vec<T> type actually works. But Vec<T> is a library type, and uses unsafe code, which is kind of definition-ally code that the compiler cannot understand. So, even for this specific case, it is too hard to do so today. A human cannot even tell if this is okay or not, right now, because you'd need to see the code that's in the `...`. 2. Even if it could, it's unclear if it's a good idea. The more complex analysis a compiler can do, the harder it is to explain what it's doing to end-users. Imagine that, for example, we wrote this code, with the `...` being a case where it's safe, but then we modified it to a case where `...` was not safe anymore. What would that diagnostic look like? How could it be communicated to people in a useful way? 3. There's a tension here. If you make it work for very specific reasons, any small changes would likely cause it to break, whereas it breaking up front may lead you toward a design that is overall more robust. > It's essentially what persistent data structures in functional languages do and it may not be a good fit for Rust. We have those! https://crates.io/crates/im https://crates.io/crates/im > Rust can sometimes feel restrictive in situations where having both mutable and immutable references or more than one mutable reference to the same thing is reasonably safe, such as in the local scope. It depends! You're not wrong, but also see my comment over here: https://news.ycombinator.com/item?id=22466587 https://news.ycombinator.com/item?id=22466587 even local scope may not be enough.
- deleted 7y ago
  [deleted]
deleted 7y ago
[deleted]
oconnor663 7y ago
These things are all related, but in my mind this part is more focused on the reference lifetime rules than the reference aliasing rules. As in, even if there's only one reference in the world, we still can't drop() the thing it refers to while the reference exists.

pedrocr 7y ago

> I'm not so sure whether Rust's strong immutability/exclusivity guarantees are worth the trouble though. Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context. For the multi threaded context it's amazing. Compile-time data-race checking is such a unique and useful feature. That and the great ergonomics of the locking primitives makes multi-threaded programming in rust really enjoyable.

oconnor663 7y ago
> great ergonomics of the locking primitives I think this is a really underrated benefit of the ownership model. You cannot forget to acquire a lock, and you cannot keep a reference to a lock's contents past the point where you've released it.

pornel 7y ago

> at least not in a single threaded context. That's the beauty of Rust: it assumes single-threaded programs don't exist. All types — including all 3rd party libraries — are forced to be either thread-safe or explicitly not compile if they'd cross thread boundaries. Nobody has "but I don't support multi threaded programs" excuse, so you may as well throw multithreading at everything.

cogman10 7y ago

> Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context. Oh, it has for me. In fact, unexpected mutation has been one of the most difficult bugs I've encountered. I had a method, foo, which when given a NavigableMap (java), it would throw an exception. However, if you called the same method with the same Map, no exception would be thrown (because the map was mutated deep down). Turns out, in the 84th circle of hell after a sub-sub-sub map view was created. A cute little said something like 'if key doesn't exist, associate key with 0'. Because NavigableMap views are mutable in java this eventually made it's way all the way back to the parent map which, consequentially, caused the map to go down a different path when the same method was re-invoked. It took a very long time to ultimately find that mutation due to the complexity of the code.

randyrand 7y ago

Sounds like you should be using shared_ptr! It guarantees to keep the object around.

fauigerzigerk 7y ago
If it's my choice to make and it's not performance critical code then I can do that. But in many cases I'm using APIs designed by others. Most older libraries come with their own idiosyncratic memory management patterns. Even the standard library has lots of different ways of passing reference-like things around. E.g. https://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view https://en.cppreference.com/w/cpp/string/basic_string_view/b...