14 ms·

Maybe "trap door" is a better word. My point is that these constructs exist so that you can do things with Rust that Rust isn't really ideal for. Any language

Maybe "trap door" is a better word. My point is that these constructs exist so that you can do things with Rust that Rust isn't really ideal for. Any language or framework has cases that don't fit its golden path, and any (useful) one will have these trap-doors so that those cases aren't totally impossible. Another (more extreme) one that Rust has is unsafe { } blocks. Rc/Arc/RefCell move guarantees to runtime; unsafe { } removes them completely. And this is well and good: real-world requirements are messy and varied and rarely fit neatly into a predetermined model. But heavy use of trap-doors is a code smell, and may be an indicator that you're using the wrong language or framework for the job.

zozbot234 6y ago
> My point is that these constructs exist so that you can do things with Rust that Rust isn't really ideal for. And this is where I disagree. Shared mutable state and multiple ownership via automated reference counting are legitimate patterns in a system programming language, and using Rc, Cell, RefCell, etc. enables these patterns in a way that preserves memory safety. That's pretty close to ideal, especially when compared to what you often see in C/C++.
- brundolf 6y ago
  I haven't done much of what could be called "systems work" in my time with Rust, so it's hard for me to comment on that, but I would tend to assume the overhead of these constructs would be extra unappealing in that context, and that instead people would do some combination of re-structuring their code to fit the ownership model and/or using unsafe { }. I guess it also depends on how much memory "churn" your program has. Maybe an operating system keeps objects around for a long time, in which case the overhead of reference-counting diminishes towards negligible. But a web server will typically allocate a bunch of memory and then throw it all away on a per-request basis. If all of this is happening behind ref-counters, I think it will start to become noticeable. Of course, for many kinds of web servers it's very possible to accomplish your goal using single-ownership. But it sounded like that wasn't true in the OP's case.
  - dgolubets 6y ago
    Assuming something is not very useful cognitive tool. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ A typical web server application has absolutely no problems with Arcs. They will be just a small percentage of overall number of objects allocated. Most of the time it's just your application dependencies\components that you need shared access to.

zozbot234 6y ago

> My point is that these constructs exist so that you can do things with Rust that Rust isn't really ideal for. And this is where I disagree. Shared mutable state and multiple ownership via automated reference counting are legitimate patterns in a system programming language, and using Rc, Cell, RefCell, etc. enables these patterns in a way that preserves memory safety. That's pretty close to ideal, especially when compared to what you often see in C/C++.

brundolf 6y ago
I haven't done much of what could be called "systems work" in my time with Rust, so it's hard for me to comment on that, but I would tend to assume the overhead of these constructs would be extra unappealing in that context, and that instead people would do some combination of re-structuring their code to fit the ownership model and/or using unsafe { }. I guess it also depends on how much memory "churn" your program has. Maybe an operating system keeps objects around for a long time, in which case the overhead of reference-counting diminishes towards negligible. But a web server will typically allocate a bunch of memory and then throw it all away on a per-request basis. If all of this is happening behind ref-counters, I think it will start to become noticeable. Of course, for many kinds of web servers it's very possible to accomplish your goal using single-ownership. But it sounded like that wasn't true in the OP's case.
- dgolubets 6y ago
  Assuming something is not very useful cognitive tool. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ A typical web server application has absolutely no problems with Arcs. They will be just a small percentage of overall number of objects allocated. Most of the time it's just your application dependencies\components that you need shared access to.