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.
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.
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)
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)
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.