Hi,
Nim is a great tool.
but:
1) When you work on very platform dependent code, you have to manually add a bunch of constants and so on. Maybe the situation could be improved by using commands of the like "gcc -v -x c -E /dev/null" (or similar with other major compilers) to parse the default paths (in dectect.nim) and don't bother the user with so much chore. Wasted time because any official update or deployment cut yourself from the mainstream a bit further.
For me, here it is. I am not ready for Nim, the "price" to pay is too high right now; but it will become a superb language once you sort those issues out.
Cheers!
If you type a lot, then you need Macros and Templates.
You checked byte type?, up to 255, can be useful.
Check the docs about defining compile variables, like -d:somethingCustom then when defined(somethingCustom): # code here.
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.
I am also bitten by this far too much. There is a certain trade-off to be made here though between safety and convenience.
I think the idea is to have the best of both worlds via the lenientops module. Have you tried importing it?
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
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.
Example code?
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.
Latest Nim is not that dumb for literals:
var a: uint16
a = 5
echo a
var x: float
x = 10
x = x / 2
echo x
import math
echo sqrt(2.0)
Works fine, even the x / 2! Only sqrt(2) does not work, but that is not a big problem. The fact that Nim does not do that many automatic type conversions is good for safety and performance -- I recently ported some Ruby code to Nim and noted how many hidden type conversions where included in the Ruby code. And as Dom said, lenientOps exists now, but I think I will generally not need it.
For point 4, why do you not point him to the nice experiments of Mr Felsing:
https://hookrace.net/blog/nim-binary-size/
So we can drastically reduce executable code size if really needed.
@MarkL Note that a tiny part of your message is wrong:
become a superb language once you sort those issues out.
Your 4 points are not really Nim Issues. Nim just can not be the optimal language for everyone. For experienced C++ developers it may be OK to continue using C++, and for pure hobby programmers without interest in language design/development and without a minimal CS background, it may be better to use languages like Python with a much larger community and many cookbook example codes.
Latest Nim is not that dumb for literals: (example) Works fine, even the x / 2!
Excellent news, thank you.
The fact that Nim does not do that many automatic type conversions is good for safety and performance ... And as Dom said, lenientOps exists now, but I think I will generally not need it.
I agree but I talked about a particularly annoying - and safe - case, something like var x: uint16 = 5.uint16. But again generally I'm also leaning towards safety even if there is a price to pay (in extra keyboard typing). But it's great news that obviously clear cases are now properly handled by Nim. Lovely.
var x: uint16 = 5.uint16
var x = 5'u16
Latest Nim is not that dumb for literals:
This is not new. NIm has been able to handle these implicit conversions since pretty much forever (I checked 0.11.0 to be sure).
Where problems come into play are constants in complex types, such as ranges, tuples, and arrays. For example, the following won't work:
var x: (int16, int16) = (1, 1)
For arrays and sequences, there is a workaround by casting only the first element:
var x: seq[int16] = @[int16 1, 2, 3, 4]
For ranges (e.g. in for loops), it is generally sufficient to convert the lower bound, but that's still not pretty:
for i in 0'i16..32767:
foo(i)