> 1) When you work on very platform dependent code, you have to manually add a > bunch of constants and so on.
My current solution: a single -d:[platform] switch and an include file with some `when` logic. Probably by far not the smartest way but simple and working 2) Too picky with variables types. I ended up casting so much in my code (or pending my values with ".intx" it is not even funny anymore. You type a lot. Yes, sometimes Nim is (still) a bit dumb. When I for example assign 5 to a uint16 var it feels a bit strange to still have to write `5.uint16`. That said I strongly prefer to (keyboard) type somewhat more over guessing whether the compiler produces correct code. All in all I love Nim's correctness obsession and am willing to pay the price, particularly when considering that it's getting smarter as it evolves. 3) Working with raw memory: ... a situation where I could not modify the raw memory of my pointer. Example code? 4) Compiled program. For the exact same program (line by line translation), nim is asking for 110k bytes (-d:release). Directly written in C: 14k (-O3). 1. runtime lib overhead? 2. you _can_ tell Nim to compile the resulting C code with pretty any switches you like.
