6 ms·

Is Nim a systems programming language ? can it operate at the same level as rust and zig ?

UnnoTed 6y ago
The first phrase in Nim's home page answers that question... "Nim is a statically typed compiled systems programming language." also: "Support for various backends: it compiles to C, C++ or JavaScript so that Nim can be used for all backend and frontend needs."
rattray 6y ago
Interestingly, they claim yes – the homepage says this: > Nim is a statically typed compiled systems programming language. > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems. However, this article says that ORC, a non-deterministic and non-hard-realtime GC system, is likely to become the new default GC in the future. Perhaps they found that the "systems language for hard-realtime" wasn't as compelling a value proposition as they originally thought? Or perhaps the tradeoffs of ORC and availability of manual memory management give them confidence that it won't materially harm hard-realtime systems use-cases in practice?
- Tiberium 6y ago
  Even if ORC becomes the default no one stops you from using ARC which is 100% deterministic and hard-realtime. ORC would be enough for most normal usages, and ARC is a switch away.
- arc776 6y ago
  > the tradeoffs of ORC and availability of manual memory management For those not familiar with the language, Nim only uses GC for `seq` (dynamically sized lists like c++ vectors), `string`, and types declared with `ref`. Everything else is a stack allocated value type, or as noted in the parent, you can manually manage with pointers. > won't materially harm hard-realtime systems use-cases in practice I think this is true. I already find myself rarely using GC when writing Nim, but when you want it, it's nice yet painless. Here someone is embedding an async messagepack/JSON RPC on an ESP32: https://forum.nim-lang.org/t/6916 https://forum.nim-lang.org/t/6916 Later they compare no async, and ORC with async and find that it's "only a few ms slower than the RPC calls running with ARC and no async." While this example may not be the hardest of realtime, it does show that ORC competes with manual approaches to memory management in constrained environments.
  - rattray 6y ago
    Thank you! I'm not familiar with Nim beyond a few tutorials/docs, so this is very useful context.
babo 6y ago
Not really. As the intro of this article says, it's possible to disable GC, but you loose most of the libraries, which is one of the strengths of Nim.
- Tiberium 6y ago
  It can, ARC is really not a full-blown GC (people usually associate GC with a tracing garbage collector which ARC is not). ARC is fully suitable for writing any low-level stuff such as OSes and similar.
nimmer 6y ago
Absolutely yes. The default GC (not ARC/ORC) is not stop-the-world. "Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems."
auxym 6y ago
Nim compiles to C, so you can use it as a "better C" like rust or Zig. That said, the main difference is that it comes with a GC, or more accurately, multiple GC options that are tunable. If you cannot have GC, as in embedded, you can compile without GC, but then you lose access to the vast majority of the standard library (which is similar to rust's --no-std, from my understanding).
- pjmlp 6y ago
  Depends on which kind of embedded. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/ https://www.microej.com/
- Tiberium 6y ago
  You can use ARC/ORC just fine on embedded :) Not sure why do you think that it's impossible.
  - PMunch 6y ago
    It used to be the case that you turned the GC off when running on embedded, but you are correct that ARC/ORC runs on embedded devices and will indeed make these even easier to program against in the future. Whether running things that normally require a GC on a tiny microcontroller is a good idea is of course entirely up to the programmer.
  - deleted 6y ago
    [deleted]
gameswithgo 6y ago
Many people call Go a systems language, which by my reasoning means almost anything is. Like many words programmers use, there appears to be no agreed upon definition. Memory management in Nim is not usually totally manual so may be not top notch for all systems type tasks. But you can probably do it if you need to given how configurable memory management it.

The first phrase in Nim's home page answers that question... "Nim is a statically typed compiled systems programming language." also: "Support for various backends: it compiles to C, C++ or JavaScript so that Nim can be used for all backend and frontend needs."

rattray 6y ago

Interestingly, they claim yes – the homepage says this: > Nim is a statically typed compiled systems programming language. > Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems. However, this article says that ORC, a non-deterministic and non-hard-realtime GC system, is likely to become the new default GC in the future. Perhaps they found that the "systems language for hard-realtime" wasn't as compelling a value proposition as they originally thought? Or perhaps the tradeoffs of ORC and availability of manual memory management give them confidence that it won't materially harm hard-realtime systems use-cases in practice?

Tiberium 6y ago
Even if ORC becomes the default no one stops you from using ARC which is 100% deterministic and hard-realtime. ORC would be enough for most normal usages, and ARC is a switch away.
arc776 6y ago
> the tradeoffs of ORC and availability of manual memory management For those not familiar with the language, Nim only uses GC for `seq` (dynamically sized lists like c++ vectors), `string`, and types declared with `ref`. Everything else is a stack allocated value type, or as noted in the parent, you can manually manage with pointers. > won't materially harm hard-realtime systems use-cases in practice I think this is true. I already find myself rarely using GC when writing Nim, but when you want it, it's nice yet painless. Here someone is embedding an async messagepack/JSON RPC on an ESP32: https://forum.nim-lang.org/t/6916 https://forum.nim-lang.org/t/6916 Later they compare no async, and ORC with async and find that it's "only a few ms slower than the RPC calls running with ARC and no async." While this example may not be the hardest of realtime, it does show that ORC competes with manual approaches to memory management in constrained environments.
- rattray 6y ago
  Thank you! I'm not familiar with Nim beyond a few tutorials/docs, so this is very useful context.

babo 6y ago

Not really. As the intro of this article says, it's possible to disable GC, but you loose most of the libraries, which is one of the strengths of Nim.

Tiberium 6y ago
It can, ARC is really not a full-blown GC (people usually associate GC with a tracing garbage collector which ARC is not). ARC is fully suitable for writing any low-level stuff such as OSes and similar.

nimmer 6y ago

Absolutely yes. The default GC (not ARC/ORC) is not stop-the-world. "Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems."

auxym 6y ago

Nim compiles to C, so you can use it as a "better C" like rust or Zig. That said, the main difference is that it comes with a GC, or more accurately, multiple GC options that are tunable. If you cannot have GC, as in embedded, you can compile without GC, but then you lose access to the vast majority of the standard library (which is similar to rust's --no-std, from my understanding).

pjmlp 6y ago
Depends on which kind of embedded. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/ https://www.microej.com/
Tiberium 6y ago
You can use ARC/ORC just fine on embedded :) Not sure why do you think that it's impossible.
- PMunch 6y ago
  It used to be the case that you turned the GC off when running on embedded, but you are correct that ARC/ORC runs on embedded devices and will indeed make these even easier to program against in the future. Whether running things that normally require a GC on a tiny microcontroller is a good idea is of course entirely up to the programmer.
- deleted 6y ago
  [deleted]

gameswithgo 6y ago

Many people call Go a systems language, which by my reasoning means almost anything is. Like many words programmers use, there appears to be no agreed upon definition. Memory management in Nim is not usually totally manual so may be not top notch for all systems type tasks. But you can probably do it if you need to given how configurable memory management it.