4 ms·

Reading such comments on Rust I'm always wondering: are there any plans to make parallel execution a core feature of Rust? Given the safety information that the

by th0br0 11y ago

Reading such comments on Rust I'm always wondering: are there any plans to make parallel execution a core feature of Rust? Given the safety information that the compiler generates, it should be relatively straightforward to offload "pure" functions to other processors. (Although AFAIR Rust actually had the notion of pure functions initially but dropped it after some time)

Manishearth 11y ago
Not that I know of. Yes, Rust had purity, then it went away. There are some plans for constexpr-like support which may bring back some purity-like support. Being a systems language unpredictably using threads sounds like a no-no to me. But I wonder if this could be designed as a compiler plugin or something.
- schuyler3d 11y ago
  How would purity be different in Rust than any function signature without any &mut?
  - GolDDranks 11y ago
    Rust functions can still have side effects: they can access unsafely global variables and read them even without unsafe access. They can call libraries that do IO. I.e. they are not referentially transparent. Constexp would be pure, because they can't rely on ANY external state, in order to be const.
    - schuyler3d 11y ago
      OK, fair enough, but it still seems like the rust compiler has enough information to determine whether something is a pure function. It knows whether global or enclosed variables are present and it knows if any of the methods it calls have an &mut ref, which I think is needed even for IO reading
      - GolDDranks 11y ago
        Yeah, I think the compiler has enough information to do that, in principle. But there is another problem: Rust has the design principle that every language-enforced invariant should be clear just from the function signature. This has at least two benefits: the compiler doesn't have to reason about the code invariants "globally", which might slow and hard to optimize, and the APIs are clearer and the user doesn't have to know implementation details to reason about them. If there's going to be some concept of purity, according to the same principle, it'd be something that one could know just by looking at the function signatures.
      - Manishearth 11y ago
        Something could call into FFI. Or whatever. The Rust compiler tries not to talk of function kinds past the function boundary as a design principle^. So while the compiler can do a transitive search down all function calls and ensure there's no trickery, Rust doesn't want to do things like that. Inference should not extend past a function. Introducing a `pure` or `const` keyword to be applied on fns would work, that way the pureness of a function can be determined without recursing into its contents. We've had some proposals for the latter, but no full implementations or rfcs yet IIRC. It might happen. ^I think it's a design principle, at least.

by th0br0 11y ago

Manishearth 11y ago

Not that I know of. Yes, Rust had purity, then it went away. There are some plans for constexpr-like support which may bring back some purity-like support. Being a systems language unpredictably using threads sounds like a no-no to me. But I wonder if this could be designed as a compiler plugin or something.

schuyler3d 11y ago
How would purity be different in Rust than any function signature without any &mut?
- GolDDranks 11y ago
  Rust functions can still have side effects: they can access unsafely global variables and read them even without unsafe access. They can call libraries that do IO. I.e. they are not referentially transparent. Constexp would be pure, because they can't rely on ANY external state, in order to be const.
  - schuyler3d 11y ago
    OK, fair enough, but it still seems like the rust compiler has enough information to determine whether something is a pure function. It knows whether global or enclosed variables are present and it knows if any of the methods it calls have an &mut ref, which I think is needed even for IO reading
    - GolDDranks 11y ago
      Yeah, I think the compiler has enough information to do that, in principle. But there is another problem: Rust has the design principle that every language-enforced invariant should be clear just from the function signature. This has at least two benefits: the compiler doesn't have to reason about the code invariants "globally", which might slow and hard to optimize, and the APIs are clearer and the user doesn't have to know implementation details to reason about them. If there's going to be some concept of purity, according to the same principle, it'd be something that one could know just by looking at the function signatures.
    - Manishearth 11y ago
      Something could call into FFI. Or whatever. The Rust compiler tries not to talk of function kinds past the function boundary as a design principle^. So while the compiler can do a transitive search down all function calls and ensure there's no trickery, Rust doesn't want to do things like that. Inference should not extend past a function. Introducing a `pure` or `const` keyword to be applied on fns would work, that way the pureness of a function can be determined without recursing into its contents. We've had some proposals for the latter, but no full implementations or rfcs yet IIRC. It might happen. ^I think it's a design principle, at least.