5 ms·

Basically you only use GC if you declare something using a GC type. type # A `ref` type is GC and will use the heap. MyGCType = ref object fiel

by arc776 7y ago

Basically you only use GC if you declare something using a GC type. type # A `ref` type is GC and will use the heap. MyGCType = ref object fieldA: int # Otherwise ALL types are stack based. MyStackType = object fieldA: int Also GC is deferred, so if you use a GC type in a local scope that doesn't escape, you don't pay for reference counting. The only other type that use GC is `seq` (equivilent to C++ vectors) IIRC. The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. However in my experience all you need to do is just not use refs, and make your own ptr based seq (there's probably a library for this but its trivial to implement). Nim's GC is thread-local (so no stop-the-world issues), only triggered on allocate, and has realtime support via enforcing collection periods. Plus you can use other GCs if you wish (eg Boehm). More info about the GC here: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html

lmm 7y ago
> Basically you only use GC if you declare something using a GC type. So similar to C# (2000)? A useful feature to be sure, but not a major innovation. > The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. Running with the GC off (and accepting the leaks) was already a standard managed-language technique though. > Nim's GC is thread-local (so no stop-the-world issues) Well no wonder it has nice properties if it avoids all of the hard problems! What happens when you pass references between threads? > only triggered on allocate, and has realtime support via enforcing collection periods. Your link describes the realtime support as best-effort, and implies that it doesn't work for cycle collection. So honestly this doesn't seem to offer much over e.g. the tuneable GC of the JVM (which admittedly made a massive mistake in choosing defaults that prioritised batch throughput rather than latency). I do appreciate the information, and hope this isn't coming off as overly confrontational. But honestly it sounds like Nim is overselling things that are mostly within the capabilities of existing managed languages (maybe even behind them if the "GC" is only thread-local and/or not cycle-collecting).
- pjmlp 7y ago
  I think the biggest issue is that most equate GC with Java/Smalltalk style, instead of GC Modula-3/C# style.
  - balfirevic 7y ago
    Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java? Or do you mean something else?
    - pjmlp 7y ago
      CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for writing GC-free code.
      - yellowapple 7y ago
        > All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.
        pjmlp 7y ago
        Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns. Doing it in some local context is a way to minimize overall process impact. Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm. Regardless, having any form of automatic memory management in system languages is something that should have already become standard by now.

by arc776 7y ago

lmm 7y ago

> Basically you only use GC if you declare something using a GC type. So similar to C# (2000)? A useful feature to be sure, but not a major innovation. > The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. Running with the GC off (and accepting the leaks) was already a standard managed-language technique though. > Nim's GC is thread-local (so no stop-the-world issues) Well no wonder it has nice properties if it avoids all of the hard problems! What happens when you pass references between threads? > only triggered on allocate, and has realtime support via enforcing collection periods. Your link describes the realtime support as best-effort, and implies that it doesn't work for cycle collection. So honestly this doesn't seem to offer much over e.g. the tuneable GC of the JVM (which admittedly made a massive mistake in choosing defaults that prioritised batch throughput rather than latency). I do appreciate the information, and hope this isn't coming off as overly confrontational. But honestly it sounds like Nim is overselling things that are mostly within the capabilities of existing managed languages (maybe even behind them if the "GC" is only thread-local and/or not cycle-collecting).

pjmlp 7y ago
I think the biggest issue is that most equate GC with Java/Smalltalk style, instead of GC Modula-3/C# style.
- balfirevic 7y ago
  Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java? Or do you mean something else?
  - pjmlp 7y ago
    CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for writing GC-free code.
    - yellowapple 7y ago
      > All GCs have eventually to stop the world Not entirely true. Erlang's BEAM definitely doesn't need to (unless you define "world" to be a single lightweight process). Perl6's MoarVM apparently doesn't need to, either.
      - pjmlp 7y ago
        Yes, I do define it like that, there is always a stop, even pauseless collectors actually do have a stop, even if a few microns. Doing it in some local context is a way to minimize overall process impact. Just like reference counting as GC algorithm does introduce pauses, specially if implemented in a naive way. More advanced ones end up being a mini tracing GC algorithm. Regardless, having any form of automatic memory management in system languages is something that should have already become standard by now.