I really like Nim, and every now and then I go back to Nim for a side project or a small tool. A couple of things that annoyed me personally about it though:

I really like Nim, and every now and then I go back to Nim for a side project or a small tool. A couple of things that annoyed me personally about it though: - Its object orientation story is weird. There is inheritance and there are methods, but there was something off and I can't remember what. I think it did not support runtime polymorphism, which to me is one of the main points of object orientation. (e.g. you have objects of different types in the same container and you call a method on each, instead of using an `if` statement.) - Related: it had a way of specifying if a relation is covariant or contravariant. Covariance: If a TextBox is a Widget, then a Handle[TextBox] is a Handle[Widget]. Contravariance: If a function takes a list of Widget, you can pass a list of TextBox, but not vice versa. This never worked properly as far as I can see. I tried to fake it by defining implicit converters (another nice feature), but this caused extremely long compile times. - Also somewhat related: I found there is an interesting effect system. I created some annotations that allow you to say: "this code must run on the main/network thread" and it would check it at compile time! Unfortunately it got a bit messy because there was no fine grained way to say "this code requires this effect", "this code sets this effect", "this code forbids this effect", so I ended up doing a lot of casting. Granted, these were somewhat obscure features. If you use Nim as a kind of compiled python for small tools, it really shines. Its a bit unfortunate that there were a couple half-baked corners in there. But I guess that's expected if you are trying to innovate as a language. Looking forward to seeing how the language developed in the meantime!