6 ms·

I really like Nim but GC makes it a nonstarter for embedded devices. So to me Nim is in the same category as Go.

• beagle3 7y ago
  Nim could always work without a GC, and it’s getting better at it all the time. Most of the standard library does depend on GC availability, but this is being worked on.
  • Touche 7y ago
    Yeah having 2 ecosystems where some stuff depends on GC and some stuff doesn't is always going to be a turnoff to me. Glad that Odin and Zig made the decision to not.
• ezquerra 7y ago
  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).
• pjmlp 7y ago
  Gemalto, PTC, Aicas, microEJ, Astrobe seem pretty fine selling Java and Oberon based tooling and runtimes for embedded devices deployments across industrial automation, robotics and military. FSecure's foundry USB security key, runs bare metal Go, TamaGo.
• nimmer 7y ago
  This is incorrect. Nim has 5 default GC methods and the upcoming automated reference counting. It runs even on the smallest microcontrollers.