3 ms·

> I was thinking about a fully mutable context shared across threads A quote from the article: “No locks, no mutexes, no syscalls, no shared mutable data here.

> I was thinking about a fully mutable context shared across threads A quote from the article: “No locks, no mutexes, no syscalls, no shared mutable data here. There are some read-only structures context and unit shared behind an Arc, but read-only sharing shouldn’t be a problem.” As you see, the data shared across threads was immutable. However, the library they have picked was designed around Rust’s ref.counting Arc<> smart pointers. Apparently for some other use cases, not needed by the OP, that library needs to modify these objects. > I can see how a GC would solve it by not needing the RC Interestingly enough, C++ would also solve that. The language does not stop programmers from changing things from multiple threads concurrently. For this reason, very few libraries have their public APIs designed around std::shared_ptr<> (C++ equivalent of Rust’s Arc<>). Instead, what usually happens, library authors write in the documentation things like “the object you pass to this API must be thread safe” and “it’s your responsibility to make sure the pointer you pass stays alive for as long as you using the API”, and call it a day.

dagmx 5y ago
To be fair, anything you can do in C++ can be done in Rust. The language just steers you away from it unless you enter into unsafe.
- Const-me 5y ago
  > To be fair, anything you can do in C++ can be done in Rust. Technically, all programming languages are Turing-complete. Practically, various things can affect development cost by a factor of magnitude. The OP acknowledges that, they wrote "Rewriting Rune just for my tiny use case was out of the question". Just because something can be done doesn't mean it's a good idea to do that. Programming is not science, it's engineering, it's all about various tradeoffs. > The language just steers you away Such steering caused unique performance issues missing from both safer garbage collected languages, and unsafe C++. Note the OP was lucky to be able to workaround by cloning the data. If that context or unit objects would use a gigabyte of RAM, that workaround probably wouldn't work, too much RAM overhead.
  - dagmx 5y ago
    Your comment said that C++ would solve it, I was merely pointing out that Rust can solve it identically to C++ by side stepping the borrow checker. You can do so without any performance penalties as well and the code would function identically to the way it does in C++.
    - Const-me 5y ago
      > Rust can solve it identically to C++ by side stepping the borrow checker Doing that is prohibitively expensive in this particular case. It would require patching a large third-party library who uses Arc for the API: https://docs.rs/rune/latest/rune/struct.Vm.html#method.new https://docs.rs/rune/latest/rune/struct.Vm.html#method.new And the reason that library uses Arc in the API is unique to Rust.
      - dagmx 5y ago
        You're talking about the specifics of this library. As you said in your original comment, that would apply to any C++ library using shared_ptr too across the API boundary. A different non-GC language wouldn't change things, because you'd have the exact same trade off if the same decision was made. The only major difference is that Rust pushes you to Arc but C++ doesn't push you to a shared_ptr.

dagmx 5y ago

To be fair, anything you can do in C++ can be done in Rust. The language just steers you away from it unless you enter into unsafe.

Const-me 5y ago
> To be fair, anything you can do in C++ can be done in Rust. Technically, all programming languages are Turing-complete. Practically, various things can affect development cost by a factor of magnitude. The OP acknowledges that, they wrote "Rewriting Rune just for my tiny use case was out of the question". Just because something can be done doesn't mean it's a good idea to do that. Programming is not science, it's engineering, it's all about various tradeoffs. > The language just steers you away Such steering caused unique performance issues missing from both safer garbage collected languages, and unsafe C++. Note the OP was lucky to be able to workaround by cloning the data. If that context or unit objects would use a gigabyte of RAM, that workaround probably wouldn't work, too much RAM overhead.
- dagmx 5y ago
  Your comment said that C++ would solve it, I was merely pointing out that Rust can solve it identically to C++ by side stepping the borrow checker. You can do so without any performance penalties as well and the code would function identically to the way it does in C++.
  - Const-me 5y ago
    > Rust can solve it identically to C++ by side stepping the borrow checker Doing that is prohibitively expensive in this particular case. It would require patching a large third-party library who uses Arc for the API: https://docs.rs/rune/latest/rune/struct.Vm.html#method.new https://docs.rs/rune/latest/rune/struct.Vm.html#method.new And the reason that library uses Arc in the API is unique to Rust.
    - dagmx 5y ago
      You're talking about the specifics of this library. As you said in your original comment, that would apply to any C++ library using shared_ptr too across the API boundary. A different non-GC language wouldn't change things, because you'd have the exact same trade off if the same decision was made. The only major difference is that Rust pushes you to Arc but C++ doesn't push you to a shared_ptr.