[12thwonder]

like Chris said in the article, it is difficult for GC languages to interop with C/C++ codebase.

in addition, if your system requires precise control over when and when not to use CPU, like resource-intensive gaming, browsers, OS, then GC may not be a good choice.

lastly, if you are using GPU via graphics API, I do not know any API that can garbage collect GPU memory but RC can naturally extend memory cleanup code to cleanup GPU memory as well quite easily.

[davnn]

CUDA.jl apparently uses Julia‘s GC to free up GPU resources, see https://cuda.juliagpu.org/stable/usage/memory/

[12thwonder]

good to know, thanks!

I personally would like to know when the GPU resources become available (freed) thus still inclined to prefer RC over GC tho.

[kazinator]

No it isn't. Chris put his foot in his mouth and went on about how an advantage of garbage collection is that it moves objects. Not all garbage collection moves objects. Garbage collection that does not move objects does not have any such interop problem. Furthermore, even GC that does move objects can avoid that particular interop problem if it simply avoids moving foreign objects. E.g. suppose a foreign object is managed by some gc-heap object of type "foreign pointer". That managing object can be moved during GC, but if the actual foreign pointer doesn't change. If that pointer is all that the foreign code knows about, then there is no problem. Don't give foreign code any pointers to your heap objects and you're good.

[hmlongco]

Uh... I can solve entire batches of problems by just saying, "don't do that and you're good."

Unfortunately, real-world constraints always seem to get in the way...