3 ms·

My path to Rust async sanity was using lots of Rc. Though at times when I'm using lots of Rc, I question why I'm not just using a GC language. I really like Go

My path to Rust async sanity was using lots of Rc. Though at times when I'm using lots of Rc, I question why I'm not just using a GC language. I really like Go as a language and you can approximate a lot of its development style by just using channels similarly in your own code. I frequently employ crossbeam channels to that effect.

felipellrocha 4y ago
I was about to say. You could avoid a ton of ‘Rc’s by just using channels instead.
xxpor 4y ago
To a certain extent, it's just enforcing what you have to do for correctness. If you have concurrency (even without parallelism), and objects are shared across contexts, you have to keep track of when objects are in use or not. The other option is enforcing exclusive access (which is just a way of maintaining a refcount of 1) At least Rust makes it easier with an Rc/Arc type! Can't tell you how many refcounting bugs I've dealt with in C since you have to remember to increment and decrement the count manually.
ncmncm 4y ago
"Using lots of Rc" is what we call Java Disease elsewhere. Usually it indicates trying to sidestep architecture problems instead of solving them. Often you Don't Care, and anything that works well enough lets you move on to the next thing. As long as you and people around you agree on the goal and tradeoffs, it is OK.
msbarnett 4y ago
> Though at times when I'm using lots of Rc, I question why I'm not just using a GC language. This seems like the wrong way to look at it? Focusing on the spots in your code where you’re using RC and concluding you ought to be using GC misses the fact that all of the spots in your app where you’re getting along fine without GC would suddenly be forced to bear the costs of GC. And RC isn’t a poor man’s GC; Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC. Unless you’re littering RCs literally everywhere, you’re probably not doing anything much worse than ARC does in Swift (in fact you’re probably doing better if you don’t do it anywhere the compiler didn’t force it, because Swift has less lifetime info and is forced to be more defensive) – you’re more than likely coming out ahead versus what your runtime costs of a GC would be. (But if you’re not concerned about runtime memory or CPU cycle costs at all, then sure, Rust is probably at the wrong level of abstraction for your problem)
- kaba0 4y ago
  > Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC I really don’t think it is true in the general case. Of course Apple will claim that, having betted on it with Swift, and also it may be true in their general niche (mobile devices with not much RAM). But if we are in a server setting with plenty of RAM available, tracing GCs of e.g. the JVM are quite green on the CPU (which is another important factor in this setting), and they provide probably the best throughput (as GC can happen on another thread concurrently)

felipellrocha 4y ago

I was about to say. You could avoid a ton of ‘Rc’s by just using channels instead.

xxpor 4y ago

To a certain extent, it's just enforcing what you have to do for correctness. If you have concurrency (even without parallelism), and objects are shared across contexts, you have to keep track of when objects are in use or not. The other option is enforcing exclusive access (which is just a way of maintaining a refcount of 1) At least Rust makes it easier with an Rc/Arc type! Can't tell you how many refcounting bugs I've dealt with in C since you have to remember to increment and decrement the count manually.

ncmncm 4y ago

"Using lots of Rc" is what we call Java Disease elsewhere. Usually it indicates trying to sidestep architecture problems instead of solving them. Often you Don't Care, and anything that works well enough lets you move on to the next thing. As long as you and people around you agree on the goal and tradeoffs, it is OK.

msbarnett 4y ago

> Though at times when I'm using lots of Rc, I question why I'm not just using a GC language. This seems like the wrong way to look at it? Focusing on the spots in your code where you’re using RC and concluding you ought to be using GC misses the fact that all of the spots in your app where you’re getting along fine without GC would suddenly be forced to bear the costs of GC. And RC isn’t a poor man’s GC; Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC. Unless you’re littering RCs literally everywhere, you’re probably not doing anything much worse than ARC does in Swift (in fact you’re probably doing better if you don’t do it anywhere the compiler didn’t force it, because Swift has less lifetime info and is forced to be more defensive) – you’re more than likely coming out ahead versus what your runtime costs of a GC would be. (But if you’re not concerned about runtime memory or CPU cycle costs at all, then sure, Rust is probably at the wrong level of abstraction for your problem)

kaba0 4y ago
> Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC I really don’t think it is true in the general case. Of course Apple will claim that, having betted on it with Swift, and also it may be true in their general niche (mobile devices with not much RAM). But if we are in a server setting with plenty of RAM available, tracing GCs of e.g. the JVM are quite green on the CPU (which is another important factor in this setting), and they provide probably the best throughput (as GC can happen on another thread concurrently)