ARC's ref is similar to C++'s shared_ptr, or Rust's Rc - with that alone it might still count as "GC'ed". But ARC also has ownership semantics, and hooks for custom containers: https://nim-lang.org/docs/destructors.html so I think it's fair to put it in the "system language" category.

In Rust/C++ it is just one of the tools. Not required thing.

Neither is it required in Nim.

A Nim object is a stack-allocated value type, without refcounting. You can put that in a heap-allocated seq (pass-by-value with move semantics), ref (refcounting), a custom container (you decide), or ptr (unsafe, like C).

I’d say the majority of Nim’s stdlib can be used without ref (arc) types. The compiler only generates ARC code if you use ref types not when you import a module.

Yeah much of the basic stdlib only uses vector, string, and map types which are similar to C++ & Rust ones with single ownership and move semantics. Static arrays can be used with many basic functions like sort.

The JSON module in Nim’s stdlib does use ref ARC types. However neither C++ nor Rust provide a JSON module by default.

Actually, a fair bit of Nim’s stdlib can even be used without allocators! Unlike Rust’s #[no_std] for embedded which is just a pain.

Arc’s are extremely common in Rust and C++ codebases.

Common, yes, although extremely common, that depends on the codebase and its goal. But they are not the default, and that what makes them system languages.

Not really, because they are not Automated Reference Counting, rather manual with explicit clone operations, in some scenarios.

Also contrary to systems where reference counting is part of the type system, and not library types, they aren't able to optimize counts away.

When this happens is as side effect of the compiler optimizing away inlined code, but not by pairing inc() with dec() operations that never leave scope.