> There have been lots of proposals to push Nim's syntax closer to Python
Indeed, many Nim users seems to have a Python background, and Python has grown a lot in the last years, see [http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html) But when you want to make Nim very similar to Python, as Crystal did it with Ruby some years ago, then traditional OOP is the largest obstacle. Some syntax differences really do not matter. But most Python code uses OOP style, which is not recommended by most Nim devs. So Python people would have to learn this new non OOP style, and would have to redesign legacy Python code. I tried to convert 8k lines of Ruby code to Nim last year. Converting syntax was no real problem. Problems are: Ruby OOP design with inheritance, Ruby containers with heterogeneous types and the absence of explicit data types, which has to be recovered for the Nim code. (Another problem, which is more a result of small Nim ecosystem, was missing libs like great GUI (so I wrote GTK bindings), RTree (I wrote one) and "Constrained Delaunay triangulation" (I started working on it). Finally, do you really recommend your Python using friends to try Nim? Why should they? Python users often have no CS background, not much demand for performance and no interest in language design. They enjoy the large Python ecosystem and are happy. Of course there are exceptions, so I indeed advertised Nim to some of my smart friends. But as these are smart, they generally know more than one language, generally the know at least C and Python. PS: I think what most scares off users is macros. When new users comes to Nim and ask something non trivial, answers is often "well, that may be possible with a macro". I know very well how deterrent this is from my LaTeX days. Got sometimes similar answer in comp.lang.tex, but at least often some kind tex experts gave me the desired macro for free.
