4 ms·

The nim team is currently working on removing the garbage collector by means of a new reference counting based “garbage collector mode” called “arc” (for automa

The nim team is currently working on removing the garbage collector by means of a new reference counting based “garbage collector mode” called “arc” (for automatic reference counting). You can get more info in the following link, where it is described as “plain old reference counting with optimizations thanks to move semantics”: https://forum.nim-lang.org/t/5734 https://forum.nim-lang.org/t/5734 The objective is to make nim suitable for embedded programming and other use cases for which garbage collection is a non starter. This new —gc:arc mode is already available in the nightly builds and the benchmarks are already impressive. I believe that the plan is to make arc the default “garbage collector mode” in nim 1.2.

Touche 7y ago
That's cool but arc is a form of GC.
gingerBill 7y ago
One of the issues with Nim is that ARC is still a form of automatic memory management, of which many domains do not want. This is why Odin has been designed to take advantage of custom allocators so that programmers have a huge control of how memory is allocated at all levels. And coupled with the `context` system, you can also have control over and track third-party code in how it allocates things. Custom allocators are a pleasure to use, and allow for so much control. Along with the temporary allocator, you can make Odin feel like it's a dynamic language whilst being extremely fast. Custom allocators are an under-utilitized thing in programming in general, and I hope more people release what is possible with them that is not possible with automatic memory management schemes.
- gavinray 7y ago
  Hey, I am going to show my stupidity for a moment but I have to ask: Why is garbage collection considered a negative thing? I have no experience programming low-level languages, but I do follow and try new/obscure languages for fun. Zig, Nim and V were the few I found + tried first, but I learned about Odin and Scopes recently and found them both interesting.
  - billforsternz 7y ago
    Garbage collection is not so much considered a negative thing, but a thing that's inappropriate for the embedded domain. The problem is that garbage collection entails some system code periodically scanning lists of memory allocations to identify stuff that's now garbage that can be recycled. Embedded Devs worry about the scheduling of that code, and how long it could take to run worst case, and whether it will spoil their real time guarantees. There are various mitigation strategies, but for good or evil many individuals and organisations apply a simple "no, we're not going to use GC ever" policy.
    - gavinray 7y ago
      @danbolt @billforsternz Thank you guys for the response, super appreciate it. I guess, I can understand from an abstract perspective that you can manually tune performance and optimize to a higher degree if you can control memory allocation yourself. And for a lot of purposes where performance is imperative, like games or embedded devices it can make or break the ability of software to function properly. But my question then is, if languages like Crystal, Nim, or D (or any other GC lang with similar speed) can operate either at/near the performance of C, why exactly do you need manual memory management? And if you do need it, I assume many languages that cater to this audience provide some sort of symbolic annotation that allow you to manually control GC where you feel you need it, aye?
      - dotbmp 7y ago
        "Near C" performance is often not good enough, and usually misleading. You can write poorly performing applications in C, and certain benchmarks may favor or disfavor certain elements of a language. Generally they're created to be "similarly written" in all benchmarked languages, which may seem like the fairest comparison at face value. But what that means is that they are often naively written in one or more of the languages. Expertly written, hand-tailored-to-the-problem-domain C code is almost always going to outperform other languages by a significant margin, especially languages without manual memory management. You can do things in C like use arena allocators to significantly reduce memory performance overhead - things which require low-level control and a non-naive understanding of the problem domain. Garbage collectors can be quite performant, but they aren't capable of this kind of insight. Code that is written in C similarly to a garbage collected language will be similarly naive (another malloc call for each and every allocated thing, versus allocating out of an arena, for instance).
- mratsim 7y ago
  Nim memory management is tied to the type you use. You either use: - an object. Which is on the stack and is either trivial or uses destructors and is suitable for embedded due to deterministic memory management - a pointer object. Which is a raw pointer like C *. Managed directly via raw malloc/free or Nim malloc/free. Suitable for embedded - a reference type. Which is managed by one of Nim GC or is an error if you use gc:none

Touche 7y ago

That's cool but arc is a form of GC.

gingerBill 7y ago

One of the issues with Nim is that ARC is still a form of automatic memory management, of which many domains do not want. This is why Odin has been designed to take advantage of custom allocators so that programmers have a huge control of how memory is allocated at all levels. And coupled with the `context` system, you can also have control over and track third-party code in how it allocates things. Custom allocators are a pleasure to use, and allow for so much control. Along with the temporary allocator, you can make Odin feel like it's a dynamic language whilst being extremely fast. Custom allocators are an under-utilitized thing in programming in general, and I hope more people release what is possible with them that is not possible with automatic memory management schemes.

gavinray 7y ago
Hey, I am going to show my stupidity for a moment but I have to ask: Why is garbage collection considered a negative thing? I have no experience programming low-level languages, but I do follow and try new/obscure languages for fun. Zig, Nim and V were the few I found + tried first, but I learned about Odin and Scopes recently and found them both interesting.
- billforsternz 7y ago
  Garbage collection is not so much considered a negative thing, but a thing that's inappropriate for the embedded domain. The problem is that garbage collection entails some system code periodically scanning lists of memory allocations to identify stuff that's now garbage that can be recycled. Embedded Devs worry about the scheduling of that code, and how long it could take to run worst case, and whether it will spoil their real time guarantees. There are various mitigation strategies, but for good or evil many individuals and organisations apply a simple "no, we're not going to use GC ever" policy.
  - gavinray 7y ago
    @danbolt @billforsternz Thank you guys for the response, super appreciate it. I guess, I can understand from an abstract perspective that you can manually tune performance and optimize to a higher degree if you can control memory allocation yourself. And for a lot of purposes where performance is imperative, like games or embedded devices it can make or break the ability of software to function properly. But my question then is, if languages like Crystal, Nim, or D (or any other GC lang with similar speed) can operate either at/near the performance of C, why exactly do you need manual memory management? And if you do need it, I assume many languages that cater to this audience provide some sort of symbolic annotation that allow you to manually control GC where you feel you need it, aye?
    - dotbmp 7y ago
      "Near C" performance is often not good enough, and usually misleading. You can write poorly performing applications in C, and certain benchmarks may favor or disfavor certain elements of a language. Generally they're created to be "similarly written" in all benchmarked languages, which may seem like the fairest comparison at face value. But what that means is that they are often naively written in one or more of the languages. Expertly written, hand-tailored-to-the-problem-domain C code is almost always going to outperform other languages by a significant margin, especially languages without manual memory management. You can do things in C like use arena allocators to significantly reduce memory performance overhead - things which require low-level control and a non-naive understanding of the problem domain. Garbage collectors can be quite performant, but they aren't capable of this kind of insight. Code that is written in C similarly to a garbage collected language will be similarly naive (another malloc call for each and every allocated thing, versus allocating out of an arena, for instance).
mratsim 7y ago
Nim memory management is tied to the type you use. You either use: - an object. Which is on the stack and is either trivial or uses destructors and is suitable for embedded due to deterministic memory management - a pointer object. Which is a raw pointer like C *. Managed directly via raw malloc/free or Nim malloc/free. Suitable for embedded - a reference type. Which is managed by one of Nim GC or is an error if you use gc:none