• solrize@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    5 days ago

    I had the impression Rust doesn’t handle concurrency particularly well, at least no better than Python, which does it badly (i.e. with colored functions). Golang, Erlang/Elixir, and GHC (Haskell) are way better in that regard, though they each have their own unrelated issues. I had believed for a while that Purescript targeting the Erlang VM and with all the JS tooling extirpated might be the answer, but that was just a pipe dream and I don’t know if it was really workable.

    • Solemarc@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      5 days ago

      Rust makes multi threading very easy you can just use

      thread::spawn();
      

      But rust makes Async difficult because it’s naturally stackless so you need to create your own scheduler or use someone else’s like Tokio. Also, people have a bad habit of conflating async with concurrency which makes it more confusing.

      • solrize@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        5 days ago

        Sure you can spawn threads but now you have all the hazards of shared memory and locks, giving the 2.0 version of aliasing errors and use-after-free bugs. Also, those are POSIX threads, which are quite heavyweight compared to the in-process multitasking of Golang etc. So I would say that’s not really an answer.

        • bamboo@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 days ago

          What exactly are the hazards of shared memory and locks? The ownership system and the borrow checker do a pretty good job at enforcing correct usage, and if you are clever you can even guarantee no deadlocks (talk at rustconf 2024 about the fuchsia network stack).