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
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.