I really like Nim, and every now and then I go back to Nim for a side project or a small tool.<p>A couple of things that annoyed me personally about it though:<p>- 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.)<p>- 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.<p>- 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.<p>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!
I would really like to see more work on improving the use of Nim for programming microcontrollers. I stumbled on to <a href="https://github.com/elcritch/nesper" rel="nofollow">https://github.com/elcritch/nesper</a> recently and it looks neat, but I had issues getting my code to compile. Improved support for other MCUs like the esp8266 and atmega32u4 would be really cool and useful. It would be nice to have Nim as a higher level alternative to micropython or lua in the embedded world (your only other real alternatives being C/C++ or Rust).<p>I also found this <a href="https://disconnected.systems/blog/nim-on-adruino" rel="nofollow">https://disconnected.systems/blog/nim-on-adruino</a>
Nim is my favorite I-hope-it-suceeds-language: fast, garbage collected, cross-platform, single binary deployment. I have not written anything more than a few toys, but ticks all of my boxes. However, still stuck in the chicken-and-the-egg problem: hard for me to invest time in the platform because it is so young.
I had previously added Nim stdlib to the techempower benchmarks as I wanted to better understand what is it that Nim lacks from a webdev perspective.<p>That exerciise taught me that, more than anything else, Nim needs good DB drivers with async support. The current driver are terrible and are the main reason why Nim is practically useless for web dev.<p>The language itself is fine. the std lib supports creating simple web projects without using any framework at all. All the maintainers need to focus on is good connectivity to the dbs. For postgres, even wrapping libpq would be a great start.
Don’t have anything to add to the survey, but I have fun with Nim every time I sketch something out in it. When I get more time, I’m looking forward to using it for some arduino development.
I would love to see Nim used more in web development. I have a strong irrational dislike for go, and Nim feels right to me as alternative. Unfortunately without corporate support, it's hard...