5 ms·

Rust has a bunch of these while being maintainable.

whateveracct 1y ago
What about Haskell concurrency isn't maintainable? The concurrency stuff in the stdlib + the mainstays in the ecosystem are pretty stable and noncontroversial..there's stuff in Haskell that churn but this is not one of them.
mrkeen 1y ago
STM is Haskell's feature for safe shared&mutable state. What is Rust's feature for safe shared&mutable state?
- speed_spread 1y ago
  That would be Arc<Mutex<T>>, which works but is no STM.
  - Philpax 1y ago
    Additionally, the actor model is pretty easy to implement: https://ryhl.io/blog/actors-with-tokio/ https://ryhl.io/blog/actors-with-tokio/
- zozbot234 1y ago
  Relevant: https://github.com/Marthog/rust-stm https://github.com/Marthog/rust-stm which has usage instructions. It's memory safe as defined in Safe Rust, but unlike the Haskell implementation it's not "safe" in a correctness sense, because Rust does not afford the same control about mutability and purity. (At least, not yet - future additions to the language may improve this somewhat.)
ykonstant 1y ago
Isn't concurrency in Rust a notorious pain point? Or am I confusing it with async which is different? [I am stuck in an era before parallelism, so I don't really understand these things]
- mrkeen 1y ago
  This why I haven't fully embraced Rust yet. Whenever I ask about safely mutating shared state (see sibling comment), I'm met with silence, or some comment like: Rust guarantees that you aren't mutating shared state.
  - sriram_malhar 1y ago
    I'm surprised you say this. The core type system guarantees is that there is no aliasing while mutating, and no mutation while it is aliased. You get single writer multiple reader for free without overhead. If you want multiple writers, you can always use the Arc container and use the built-in lock.
    - mrkeen 1y ago
      >> or some comment like: Rust guarantees that you aren't mutating shared state. > The core type system guarantees that there is no [sharing] while mutating, and no mutation while [sharing]
      - sriram_malhar 1y ago
        Not sure what you are pointing out, so let me spell out what I said earlier. 1. You get single-writer multiple reader for free from the type system, without any runtime overhead. 2. For the same reason, the type system does not allow multiple writers. If you want multiple writers, then you are forced to use locks. Once you use locks, the runtime guarantees safety for this case. Either way, you get 100% safety.
        mrkeen 1y ago
        You're not adding any new information. I already understand you completely. > 1. You get single-writer multiple reader for free from the type system, without any runtime overhead. Take the example from the article which is accepted by the Haskell type system: writeTBCQueue :: TBCQueue a -> a -> STM () writeTBCQueue q v = do stillOpen <- readTVar q.open when stillOpen $ writeTBQueue q.queue v Rust would reject this because of multiple writers. Also, thinking about it more, I'm now very skeptical of Rust even providing 'single-writer multiple-reader'. Is it in fact single-reader-writer xor multiple-reader? In other words, how does it handle a goblin constantly moving money between accounts while a gnome is constantly trying to count the total amount? goblinBankerThread = forever $ do seed <- randomSeed atomically $ do (acctA, acctB) <- chooseTwoRandomAccounts seed if (amount acctA) > (amount acctB) then moveAmount $5 acctA acctB else moveAmount $5 acctB acctA gnomeAccountantThread = forever $ atomically $ do accounts <- readAllAccounts assert someConstantAmount allAccounts Yes, Rust is 100% safe because it would reject this code, so it would never run. Not running code also has guaranteed no-overhead! 2. For the same reason, the type system does not allow multiple writers. If you want multiple writers, then you are forced to use locks * Locks are problematic, which is why I chose STM over locks in the first place. * Locks are in all the languages. Does your comment about 100% safety really apply to all languages ?
butterisgood 1y ago
Rust is nearly the answer if anyone understood the question.

What about Haskell concurrency isn't maintainable? The concurrency stuff in the stdlib + the mainstays in the ecosystem are pretty stable and noncontroversial..there's stuff in Haskell that churn but this is not one of them.

mrkeen 1y ago

STM is Haskell's feature for safe shared&mutable state. What is Rust's feature for safe shared&mutable state?

speed_spread 1y ago
That would be Arc<Mutex<T>>, which works but is no STM.
- Philpax 1y ago
  Additionally, the actor model is pretty easy to implement: https://ryhl.io/blog/actors-with-tokio/ https://ryhl.io/blog/actors-with-tokio/
zozbot234 1y ago
Relevant: https://github.com/Marthog/rust-stm https://github.com/Marthog/rust-stm which has usage instructions. It's memory safe as defined in Safe Rust, but unlike the Haskell implementation it's not "safe" in a correctness sense, because Rust does not afford the same control about mutability and purity. (At least, not yet - future additions to the language may improve this somewhat.)

ykonstant 1y ago

Isn't concurrency in Rust a notorious pain point? Or am I confusing it with async which is different? [I am stuck in an era before parallelism, so I don't really understand these things]

mrkeen 1y ago
This why I haven't fully embraced Rust yet. Whenever I ask about safely mutating shared state (see sibling comment), I'm met with silence, or some comment like: Rust guarantees that you aren't mutating shared state.
- sriram_malhar 1y ago
  I'm surprised you say this. The core type system guarantees is that there is no aliasing while mutating, and no mutation while it is aliased. You get single writer multiple reader for free without overhead. If you want multiple writers, you can always use the Arc container and use the built-in lock.
  - mrkeen 1y ago
    >> or some comment like: Rust guarantees that you aren't mutating shared state. > The core type system guarantees that there is no [sharing] while mutating, and no mutation while [sharing]
    - sriram_malhar 1y ago
      Not sure what you are pointing out, so let me spell out what I said earlier. 1. You get single-writer multiple reader for free from the type system, without any runtime overhead. 2. For the same reason, the type system does not allow multiple writers. If you want multiple writers, then you are forced to use locks. Once you use locks, the runtime guarantees safety for this case. Either way, you get 100% safety.
      - mrkeen 1y ago
        You're not adding any new information. I already understand you completely. > 1. You get single-writer multiple reader for free from the type system, without any runtime overhead. Take the example from the article which is accepted by the Haskell type system: writeTBCQueue :: TBCQueue a -> a -> STM () writeTBCQueue q v = do stillOpen <- readTVar q.open when stillOpen $ writeTBQueue q.queue v Rust would reject this because of multiple writers. Also, thinking about it more, I'm now very skeptical of Rust even providing 'single-writer multiple-reader'. Is it in fact single-reader-writer xor multiple-reader? In other words, how does it handle a goblin constantly moving money between accounts while a gnome is constantly trying to count the total amount? goblinBankerThread = forever $ do seed <- randomSeed atomically $ do (acctA, acctB) <- chooseTwoRandomAccounts seed if (amount acctA) > (amount acctB) then moveAmount $5 acctA acctB else moveAmount $5 acctB acctA gnomeAccountantThread = forever $ atomically $ do accounts <- readAllAccounts assert someConstantAmount allAccounts Yes, Rust is 100% safe because it would reject this code, so it would never run. Not running code also has guaranteed no-overhead! 2. For the same reason, the type system does not allow multiple writers. If you want multiple writers, then you are forced to use locks * Locks are problematic, which is why I chose STM over locks in the first place. * Locks are in all the languages. Does your comment about 100% safety really apply to all languages ?

butterisgood 1y ago

Rust is nearly the answer if anyone understood the question.