I believe the phrasing might not be clear to everyone, so here's a reduced version:

* Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them.

* ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success.

* This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC.

TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡.

† We are not sure that it's bug-free yet, which is why it's not the default for this release.

‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.

Your explanation is very clear. Thanks.

I think you missed this detail:

> ARC was first shipped with Nim 1.2... [ORC is] our main new feature for this release

Seems like they should phrase it like "use ORC unless you know you don't have cycles" rather than "use ORC if you're not sure you have cycles", but that's a reasonable responsibility to take on if you're choosing to use an alternative garbage collector.

I'd prefer no phrasing at all. Just pick one that will work well in all cases, and don't give me any footguns.

To clarify: By default Nim will still use the GC which doesn't have any "footguns". ARC and ORC are new features which have different trade-offs, and some limitations. You opt-in to using them if you're interested.

A way of dealing with memory that works well in all cases! That would be great.

Yes. Or at least put them in the appendix.

Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.

If I recall correctly, I read that the intention is to eventually make ORC the default, not ARC. (ORC is like ARC, but it avoids problems with cycles.)

Yes, you're totally right! That's the exact reason ORC should eventually become the new default GC.

Sorry if you got misled by the article - ORC is what you should use if your program has cycles. ORC deals with async just fine.

Does ORC stand for something?

I could be wrong, but I believe the acronyms are: ARC = Automatic Reference Counting (NOTE: not Atomic) ORC = Optimized Reference Counting

The loopy/circular character of the letter 'O' may be a secondary mnemonic since it collects cycles.

I meant "character" as in "nature" not as in the prog.lang "character type"..I just realized that in context this might be confusing. Lol.

At an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.

Yes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.

Note that what we're referring to as "async" for Nim is actually "async await". AFAIK Swift doesn't support that, does it?

Swift doesn't claim hard realtime capabilities like Nim's ARC does.

I'm not familiar with Nim. Does it also support weak references?

A significant portion of the problems with cycles in ARC are parent references.

Weak references are possible with the .cursor pragma applied on local variables and object fields. This release introduces cursor inference too, enabled by default with --gc:arc|orc, but only for local variables.

Is there an msan/asan equivalent that can detect leaks in your test suite?

Yes, we use valgrind for the compiler and stdlib test suite. The testament tool supports this, however it's not in widespread use outside of the compiler and stdlib, so documentation is rather sparse.

Since Nim uses the C compiler to generate executables, you should be able to use `--passC:-fsanitize=memory --passL:-fsanitize=memory` to enable msan. For maximum effectiveness the flags `-d:useMalloc --gc:orc` should also be used.

`-d:useMalloc` tells Nim to allocate memory using libc's malloc instead of our TSLF implementation. This should provide adequate compatibility for use with external inspection tools. We do

`--gc:orc` because this is one of the only GCs that support -d:useMalloc (the other being arc).

Please put this in the docs, if it is not there already