6 ms·

> Usually a project is oxidised into Rust because of many reasons, the main usually being memory safety. What about python’s memory model is unsafe?

pohl 4y ago
Does Python do anything to enforce mutually exclusive access when mutating? If not, that’s a hole you could drive a truck through, isn’t it?
- gpm 4y ago
  Isn't Python still run under a single global interpreter lock? Can't have simultaneous access while mutating if only one thing is running at a time...
  - pohl 4y ago
    Yeah, that’s something, at least. Wouldn’t the order that mutations happen still matter, even though they have to acquire a lock? Not a pythoneer, myself.
    - masklinn 4y ago
      Not in the context of memory safety. You can still have race conditions up the ass, but not data races, unless you're using a native library which 1. releases the GIL and 2. is broken.
      - pohl 4y ago
        Interesting, I hadn’t realized how much the phrase “memory safety” understates what is desirable.
        gpm 4y ago
        The thing is that races are good a lot of the time. If I have a set of tasks running in parallel that take an unknown/variable amount of time and I want to tell the users which ones are finished, my output needs to be based on a race between the tasks. If I'm scraping a website, I (may) want to have multiple connections going in parallel, and as soon as one of those connections spots a new link I (may) want to open a new connection to start scraping it, but I don't know which connection is going to spot a new link first, so there's a (benign) race condition. Making a language that banned them outright would be making a language that couldn't do things that people wanted to do.
        Yoric 4y ago
        I figure that you could very easily mark which race conditions are good.
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
    - gpm 4y ago
      Matter? Sure, there can be race conditions. But allow for memory unsafety? No, not if every ordering of the "critical sections" (chunks of code run as a unit while the interpreter is locked) is valid and upholds the invariants Python expects.
  - tialaramex 4y ago
    For so long as the GIL persists, you are correct, and thus Python does not have data races and is able to achieve memory safety in this regard. It is conceivable (but extremely unlikely, 'cos it was really, really hard) that after a GILectomy Python follows the Java path, in which data races are technically safe†. However it is most likely Python with a GILectomy will behave like Go or C# or numerous other languages and lose memory safety properties if a data race occurs. † Data races can happen in Java, and astonishing things might happen, but objects always remain in some valid state, so there is no loss of memory safety whereas in most languages with data races you can e.g. race a hash table and mess up its internals and cause chaos.
brundolf 4y ago
The article felt kind of disjointed, I think that statement was just meant generally and not meant to suggest it applies here
- masklinn 4y ago
  Also how I interpreted it, though even there it's quite weird (e.g. better performances is also a common reason to convert things to Rust, especially when "easy binding" tools like pyo3, neon, or rustler are available and take care of the unsafe bits between the two).
  - tialaramex 4y ago
    On the other hand, performance isn't a unique thing Rust brings to the party, C or C++ both have attractive performance in the same ballpark. So if the question is "Why Rust specifically?" rather than e.g. "Couldn't I technically use an awk script?" then safety is a better argument than performance. Rather than memory safety per se, I'd actually value Rust's type safety over Python's. Yes, strictly speaking Python is dynamically typed rather than untyped, but Rust will shift a lot of your mistakes "hard left" (ie report your goof during compilation not during execution) compared to Python because it gets to do these checks up front, and it is also able to catch a lot more of them because it's much stricter about what types are. In Python we can write "if foo" and it doesn't matter too much what type foo actually has, Python will try to decide if it's "truthy" at runtime. In Rust either foo is a boolean, in which case this is a reasonable thing to do, or it isn't, that's a type mismatch, your program doesn't compile. Not everyone loves this, but I certainly do.
- UncleEntity 4y ago
  Yeah… It’s becoming a pet peeve that the Rustafarians believe they have a monopoly on “memory safety” and need to point it out all the time.
  - shaunsingh 4y ago
    Its worth pointing out because rust has a monopoly on easy-to-write gc-less memory safety, with the alternatives being modern c++ or higher level languages where you run into a garbage collector

pohl 4y ago

Does Python do anything to enforce mutually exclusive access when mutating? If not, that’s a hole you could drive a truck through, isn’t it?

gpm 4y ago
Isn't Python still run under a single global interpreter lock? Can't have simultaneous access while mutating if only one thing is running at a time...
- pohl 4y ago
  Yeah, that’s something, at least. Wouldn’t the order that mutations happen still matter, even though they have to acquire a lock? Not a pythoneer, myself.
  - masklinn 4y ago
    Not in the context of memory safety. You can still have race conditions up the ass, but not data races, unless you're using a native library which 1. releases the GIL and 2. is broken.
    - pohl 4y ago
      Interesting, I hadn’t realized how much the phrase “memory safety” understates what is desirable.
      - gpm 4y ago
        The thing is that races are good a lot of the time. If I have a set of tasks running in parallel that take an unknown/variable amount of time and I want to tell the users which ones are finished, my output needs to be based on a race between the tasks. If I'm scraping a website, I (may) want to have multiple connections going in parallel, and as soon as one of those connections spots a new link I (may) want to open a new connection to start scraping it, but I don't know which connection is going to spot a new link first, so there's a (benign) race condition. Making a language that banned them outright would be making a language that couldn't do things that people wanted to do.
        Yoric 4y ago
        I figure that you could very easily mark which race conditions are good.
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
    - deleted 4y ago
      [deleted]
  - gpm 4y ago
    Matter? Sure, there can be race conditions. But allow for memory unsafety? No, not if every ordering of the "critical sections" (chunks of code run as a unit while the interpreter is locked) is valid and upholds the invariants Python expects.
- tialaramex 4y ago
  For so long as the GIL persists, you are correct, and thus Python does not have data races and is able to achieve memory safety in this regard. It is conceivable (but extremely unlikely, 'cos it was really, really hard) that after a GILectomy Python follows the Java path, in which data races are technically safe†. However it is most likely Python with a GILectomy will behave like Go or C# or numerous other languages and lose memory safety properties if a data race occurs. † Data races can happen in Java, and astonishing things might happen, but objects always remain in some valid state, so there is no loss of memory safety whereas in most languages with data races you can e.g. race a hash table and mess up its internals and cause chaos.

brundolf 4y ago

The article felt kind of disjointed, I think that statement was just meant generally and not meant to suggest it applies here

masklinn 4y ago
Also how I interpreted it, though even there it's quite weird (e.g. better performances is also a common reason to convert things to Rust, especially when "easy binding" tools like pyo3, neon, or rustler are available and take care of the unsafe bits between the two).
- tialaramex 4y ago
  On the other hand, performance isn't a unique thing Rust brings to the party, C or C++ both have attractive performance in the same ballpark. So if the question is "Why Rust specifically?" rather than e.g. "Couldn't I technically use an awk script?" then safety is a better argument than performance. Rather than memory safety per se, I'd actually value Rust's type safety over Python's. Yes, strictly speaking Python is dynamically typed rather than untyped, but Rust will shift a lot of your mistakes "hard left" (ie report your goof during compilation not during execution) compared to Python because it gets to do these checks up front, and it is also able to catch a lot more of them because it's much stricter about what types are. In Python we can write "if foo" and it doesn't matter too much what type foo actually has, Python will try to decide if it's "truthy" at runtime. In Rust either foo is a boolean, in which case this is a reasonable thing to do, or it isn't, that's a type mismatch, your program doesn't compile. Not everyone loves this, but I certainly do.
UncleEntity 4y ago
Yeah… It’s becoming a pet peeve that the Rustafarians believe they have a monopoly on “memory safety” and need to point it out all the time.
- shaunsingh 4y ago
  Its worth pointing out because rust has a monopoly on easy-to-write gc-less memory safety, with the alternatives being modern c++ or higher level languages where you run into a garbage collector