4 ms·
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
by geenat 4y ago
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 4y agoMacros shouldn’t have any performance implications. The whole point is that they happen at compile time.
- cb321 4y agoHe 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 4y ago100% about compile times. Sorry, wasn't clear about that.
- PMunch 4y agoHave 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.