3 ms·

This is quite impossible for a language in Rust’s space; it would violate Rust’s principle of only paying for what you use, because there is necessarily runtime

This is quite impossible for a language in Rust’s space; it would violate Rust’s principle of only paying for what you use, because there is necessarily runtime overhead in providing such an abstraction.

tjoff 5y ago
The compiler would know that in advance though? Thus you only pay for it if it is required.
- chrismorgan 5y ago
  Threads and async have different restrictions and costs. No shared abstraction is possible for a language like Rust without losing what makes it Rust. Minimal-cost threading support requires taking Send + Sync into account, essentially thread-safety: and the thread-safe primitives are more expensive than the thread-local primitives. Send + Sync matters become pervasive through the design of threaded code, even if they don’t need to be spelled out most of the time. Minimal-cost async requires compiling the code into a state machine, which means you’ve got to restrict borrowing across suspend points, or mess around with Pin. Threading and async are quite different in a language like Rust. They can even play quite nicely together. But you really can’t unify them. Sure, you could do simple cases like single-threaded blocking-or-async, e.g. `async? fn foo() { bar().await; }` compiling to something like strawman `fn sync#foo() { sync#bar(); } async fn async#foo() { async#bar().await; }`, but this falls apart completely as soon as you want to do anything beyond immediate .await.
amelius 5y ago
> it would violate Rust’s principle of only paying for what you use I guess I'm glad that Rust developers don't design CPUs, as we wouldn't have memory abstractions like cache coherent NUMA (which doesn't come for free).
- adwn 5y ago
  Who said anything about "free"? chrismorgan wrote "only paying for what you use". In NUMA systems, pretty much every program uses and benefits from cache coherency.
  - amelius 5y ago
    And is it still free if you don't want to use it?
    - adwn 5y ago
      Well, that depends on the details of the CPU architecture in question. Without knowing those details, I'd say probably yes, but userspace programs will need to ask the kernel to change the memory attributes of the mapped area they want to access non-coherently. Case in point: a CPU plus a discrete GPU is technically a NUMA system, and low-level APIs like Vulkan explicitly expose the ability to allocate non-coherent memory. I strongly assume that accessing that memory doesn't incur coherency overhead.
      - amelius 5y ago
        In short, CPU designers gave us the choice, whereas Rust only gives us "the Rust way or the highway".
        adwn 5y ago
        > Rust only gives us "the Rust way or the highway" What are you even talking about? Rust gives you plenty of choice, it even lets you create as many "non-free" abstractions as you'd like.
        amelius 5y ago
        But not at the language level, which is what started this thread. As another example: compare "GC'd versus non-GC'd memory in Rust" to "coherent versus non-coherent memory in CPU architecture"; here Rust gives us just the bare machine, while CPU architects give us quite some abstraction plus a choice. It is true that you could theoretically write a GC in Rust, but using it from the language itself would probably break ergonomics so much that you'd be better off with another language.

tjoff 5y ago

The compiler would know that in advance though? Thus you only pay for it if it is required.

chrismorgan 5y ago
Threads and async have different restrictions and costs. No shared abstraction is possible for a language like Rust without losing what makes it Rust. Minimal-cost threading support requires taking Send + Sync into account, essentially thread-safety: and the thread-safe primitives are more expensive than the thread-local primitives. Send + Sync matters become pervasive through the design of threaded code, even if they don’t need to be spelled out most of the time. Minimal-cost async requires compiling the code into a state machine, which means you’ve got to restrict borrowing across suspend points, or mess around with Pin. Threading and async are quite different in a language like Rust. They can even play quite nicely together. But you really can’t unify them. Sure, you could do simple cases like single-threaded blocking-or-async, e.g. `async? fn foo() { bar().await; }` compiling to something like strawman `fn sync#foo() { sync#bar(); } async fn async#foo() { async#bar().await; }`, but this falls apart completely as soon as you want to do anything beyond immediate .await.

amelius 5y ago

> it would violate Rust’s principle of only paying for what you use I guess I'm glad that Rust developers don't design CPUs, as we wouldn't have memory abstractions like cache coherent NUMA (which doesn't come for free).

adwn 5y ago
Who said anything about "free"? chrismorgan wrote "only paying for what you use". In NUMA systems, pretty much every program uses and benefits from cache coherency.
- amelius 5y ago
  And is it still free if you don't want to use it?
  - adwn 5y ago
    Well, that depends on the details of the CPU architecture in question. Without knowing those details, I'd say probably yes, but userspace programs will need to ask the kernel to change the memory attributes of the mapped area they want to access non-coherently. Case in point: a CPU plus a discrete GPU is technically a NUMA system, and low-level APIs like Vulkan explicitly expose the ability to allocate non-coherent memory. I strongly assume that accessing that memory doesn't incur coherency overhead.
    - amelius 5y ago
      In short, CPU designers gave us the choice, whereas Rust only gives us "the Rust way or the highway".
      - adwn 5y ago
        > Rust only gives us "the Rust way or the highway" What are you even talking about? Rust gives you plenty of choice, it even lets you create as many "non-free" abstractions as you'd like.
        amelius 5y ago
        But not at the language level, which is what started this thread. As another example: compare "GC'd versus non-GC'd memory in Rust" to "coherent versus non-coherent memory in CPU architecture"; here Rust gives us just the bare machine, while CPU architects give us quite some abstraction plus a choice. It is true that you could theoretically write a GC in Rust, but using it from the language itself would probably break ergonomics so much that you'd be better off with another language.