Support for embedded is indeed getting into focus. I hope to release an article soon how the '--gc:regions' switch works (which is misnamed, it's a way to do memory management, not a GC...) and in the longer run the destructor-based runtime will ensure that memory is freed sooner than a GC would for memory constrained devices.
Having said that, "embedded" is a wide field and sometimes one cannot even afford a heap, no matter if garbage collected or managed manually. But even then Nim can be used, you still get array bounds checking, Ada-inspired strong type checking plus the meta programming goodies.
I agree that 'discard' is usually a code smell, but how would implicitly ignoring the result be any better? It wouldn't be better at all, and that means Nim's discard feature is rather well designed as it improves the status quo.
I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.
That's true and I wouldn't use the Option type for that either. There is a switch that warns about variables that are not initialized explicitly (including the 'result' variable) and an RFC to make this switch non-optional. https://github.com/nim-lang/Nim/issues/7917
> But to ask a pointed question, doesn't that mean Nim gets the worst of both worlds? You have both the overhead of updating reference counts and the (relatively long) garbage collection pauses.
There's a patch of the collector to make the M&S incremental, to avoid pauses for this step too. Of course, whether a deferred RC'ing GC with incremental cycle collector works better in practice than a more conventional generational incremental GC (or just an incremental GC) is an open question. :-)
Nim has garbage collected pointers (ref) and raw pointers (ptr). You can use 'ptr' to break up cycles manually and disable the M&S. I suppose it's very much comparable to Swift except that Nim's RC overhead is much lower since it's deferred RC.
> There are other ways to address this issue. You can do what Swift does and call into libclang so that you can pull out the structure definitions, for instance.
Sure and you only need to call libclang for each different platform. Or is it on every platform? ;-)
Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.
Good questions. I'm afraid the documentation is seriously out of date about the GC: It used to implement a variant of "trial deletion" so that "never scans the whole heap" used to refer to the fact that it doesn't use traditional mark&sweep, but only scans the subgraph(s) leading to the cycles. Of course you can always create a "subgraph" that spans the whole heap, so even for trial deletion it is a dubious claim.
Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC to collect cycles. Reasons: Trial deletion in practice is much slower.
For all versions of the GC is stack is scanned conservatively as precise stack scanning is simply too expensive when C is your main target.
Having said that, "embedded" is a wide field and sometimes one cannot even afford a heap, no matter if garbage collected or managed manually. But even then Nim can be used, you still get array bounds checking, Ada-inspired strong type checking plus the meta programming goodies.