3 ms·

> Nim isn’t really a GC’ed OOP language though it supports some bits of that. I'm not sure about the OOP part, but last time I checked the standard library ass

> Nim isn’t really a GC’ed OOP language though it supports some bits of that. I'm not sure about the OOP part, but last time I checked the standard library assumed the GC was enabled, so on that side I believe it's much closer to those languages than to C/C++/Rust/Zig

elcritch 1y ago
It’s more that Nim2 moved from a GC to ARC/ORC, scope based automatic reference counting (ARC) with an optional cycle collector (ORC). C++, Swift, and even Rust rely on reference counting quite a bit.
- SkiFire13 1y ago
  As long as it's effectively required by default I would place it in a category more similar to GCed languages than system languages like C++ and Rust.
  - shiomiru 1y ago
    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 https://nim-lang.org/docs/destructors.html so I think it's fair to put it in the "system language" category.
    - timeon 1y ago
      In Rust/C++ it is just one of the tools. Not required thing.
      - shiomiru 1y ago
        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).
        elcritch 1y ago
        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.
  - binary132 1y ago
    Arc’s are extremely common in Rust and C++ codebases.
    - pjmlp 1y ago
      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.
    - afdbcreid 1y ago
      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.

elcritch 1y ago

It’s more that Nim2 moved from a GC to ARC/ORC, scope based automatic reference counting (ARC) with an optional cycle collector (ORC). C++, Swift, and even Rust rely on reference counting quite a bit.

SkiFire13 1y ago
As long as it's effectively required by default I would place it in a category more similar to GCed languages than system languages like C++ and Rust.
- shiomiru 1y ago
  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 https://nim-lang.org/docs/destructors.html so I think it's fair to put it in the "system language" category.
  - timeon 1y ago
    In Rust/C++ it is just one of the tools. Not required thing.
    - shiomiru 1y ago
      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).
      - elcritch 1y ago
        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.
- binary132 1y ago
  Arc’s are extremely common in Rust and C++ codebases.
  - pjmlp 1y ago
    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.
  - afdbcreid 1y ago
    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.