> 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)
Run
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](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.
