[geenat]

Default values and named parameters, thank you! Golang has neglected both of these. Both seemingly rare yet highly productive features to be found in a compiled language.

Love the quick compile times and go-like single binary compilation.

Case-insensitivity seems very cool for interoperability. Total underappreciated gem.

My only hangup is the syntax feels wordy, but it's leagues better compared to Rust or Go in that regard. A bit concerned about the performance cost of using macros to cut down on the wordiness (I would do this).

Otherwise great to see a 2.0 and always keeping a close eye on the Nim ecosystem as I would definitely consider adopting it.

[TylerE]

Macros shouldn’t have any performance implications.

The whole point is that they happen at compile time.

[cb321]

He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted.

EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.

[geenat]

100% about compile times. Sorry, wasn't clear about that.

[PMunch]

Have written quite a lot of macros, unless you're doing something really crazy you should be fine. The one time I've really run into macros slowing down compilation a lot was when I wrote my protobuf library which parses a protoc file during compile-time and generates all the required types and procedures. And that was mostly because the parser I used was really poorly optimized.