Besides Tiberium's and mratsim's excellent points in siblings about more recent non-tracing automatic memory management with ARC/ORC, Nim has also supported manual memory management (via raw pointers with alloc / alloc0 and dealloc) since its very beginnings (but the stdlib uses AMM almost exclusively). So, if you only do manual management and turn it off with --mm:none, memory will be freed when you dealloc (with opportunity for mistakes anything manual entails). I believe D's non-"GC" mode is the same manual style.
That page is quite a bit outdated - Nim version 1.4.0 was released in October 2020. The newest Nim 2.0 release has the default GC set to ORC, which is ARC + a cycle collector, see https://nim-lang.org/docs/mm.html.
As for ARC/ORC specifically, you can read a small introduction in https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc..., but as a TLDR: ARC is something closer to RAII than a GC (destructors injected automatically at the end of scopes) with reference counting for reference types. You can switch between ARC/ORC when compiling, and destructors give a lot of control - https://nim-lang.org/docs/destructors.html.
I want to write low level code and was considering Nim because I want to compile to C, so I can benefit from Cosmopolitan Actually Portable binaries.
Do you think Nim is feasible for this? Do you know other languages that could do that, it seems my options are VERY limited (despite there being thousands of languages, there's almost none that can compile to C and gives you good memory control)... I think Zig can't compile to C yet, Rust doesn't either (except for some experimental compiler) and other options are GC'd with a "heavy" runtime which is the last thing I want.
If something does not work for you, Yardanico is super duper helpful in all things Nim.
Nim also compiles to Javascript (nim js) and C++ for integration with legacy codebases, but that is probably more to the side of your interests.
While I have never seen it done and always meant to give it a try, compiling to C should allow one to also do things like write Linux kernel modules in Nim without any special support from the Linux team.
Nim has GC and runtime and Linux kernel developers do not allow third party runtimes in the kernel. Even meager Rust's "panic" runtime is a contentious issue. Can one disable runtime in Nim completely -- no GC, no exceptions?
> kernel developers do not allow third party runtimes in the kernel. Even meager Rust's "panic" runtime is a contentious
Much in Linux is contentious :-) which is why the module system is nice. A kernel module for C code requires no permission from Linux-core unless you need it distributed with the kernel (which, yes, might be required for "credibility" - but critically also might not). It may require many decls to access various kernel APIs, but those can be (semi-)automated or just done as-needed. So, Linux kernel policy is not so relevant (at best) which is what I meant by "no special support" (admittedly brief). Kernel coding is always a bit trickier, and you may need to build up some support code to make integration nice, though as well as decl generators (though none of that need be distributed "with Linux").
> Can one disable runtime in Nim completely -- no GC, no exceptions?
To answer your question, and as discussed elsewhere in this subthread, Nim has many options for memory management.. only stdlib seq/string really needs automatic methods. One can disable the runtime completely via os:standalone and statically check that no exceptions are raised with Nim's effect system (and there are also both setjmp & goto based exception impls which may/may not be workable in Linux/BSD kernel module settings).
As "proof more by example", a few people have written OS kernels in Nim recently[1,2] and there was another toy kernel long ago[3]. People have also written OS kernels in Go which "has a GC and runtime".[4] So, I acknowledge it's not quite the same example, but I also see no fundamental blockers for kernel modules.
type Foo = object -> no GC, stack object, can use destructors
type Foo = ptr object -> manual memory management
type Foo = ref object -> "GC", refcounting to be exact.
