For Python users, the syntax of Nim is not disturbing whereas this may be an obstacle for those using another language. But, this is a trap. Despite their syntax similarities, Python and Nim are very different languages and those who are not aware of the constraints of a statically typed and non interpreted language may be disappointed if they try to use Nim as they use Python.
OOP is indeed one of the difficulty they will encounter even if Python is more flexible that Ruby for which OOP is mandatory. In Python, OOP is one way to do things, but it exists and is heavily used. Nevertheless, I think that this is not the main difficulty. I have tried to convert a complicated library (named _pdfminer_ ) from Python to Nim and I have given up for now. OOP is used everywhere, of course, and I encountered some difficulties with inheritance and dynamic dispatch, mixing procs nd methods. But the true difficulties were: – forward references; I was constrained to change some proc interfaces, to split some modules and join others; this was a laborious task; Python users don’t care much about that; in some cases, they encounter a problem, but most of the time (especially, if they don’t use global variables) it simply works as the binding of names is done at run time; – dynamic typing; in Python, a field may contain anything; when converting to Nim, you have first to find all the locations where it is “assigned” a value (the term is not right, but it doesn’t matter); then you have either to use some form of inheritance, which will raise other difficulties, or you have to use variants; in fact, I used both approaches, but the restructuring is complex. I have never encountered such difficulties when converting my own programs from Python to Nim, because, for me, and even in Python, a field must have a type. I seldom use extreme dynamic typing in Python as it hurts readability. But other Python users have not this shyness. So, users of Python and other scripting languages such as Ruby or Lua, may have unpleasant surprises when trying to use Nim. At least, if they don’t know what is a statically typed language which compiles to native code. Moreover, I doubt that Python users will find in Nim a lot of things they don’t find in Python. More checks at compile time which they often find more as an inconvenience than an advantage. Better performance, yes, even if _pypy_ does a great job compared to _cpython_. Will this make up for the lost of flexibility? I’m not sure. I cannot say for sure what could attract Python users to Nim. I’m not the typical Python user, even if I have used the language since its version 1.6 and was quite a fan of this language. Indeed, before using Python, I mostly used statically typed and non interpreted languages which is the reason I fill comfortable with Nim. I think that users of statically typed languages which compile to native code could be a better target as they can see what are the advantages of Nim compared to other languages in the same category. Unfortunately, Nim syntax will repel a lot of potential users which are accustomed to languages using a C-like syntax. This may seem a minor aspect, but it is very important. Nevertheless, I don’t preconize for Nim to switch to a C-like syntax: I would hate that. But this is a point to be aware of. As regards macros, they add a lot of flexibility to the language and, so, are often the way to make up for Nim lack of flexibility when dealing with types. So, some people are trying to do in Nim things which would be better done in another language. Again, Nim has limitations due to its nature and even macros will not allow to deal with types at run time (except, in a certain way, when using objects and inheritance, but this has a cost). The distinction between what is done at compile time and what is done at run time is certainly one thing which may cause misunderstanding and disappointment for new users.
