Nim Community Survey
nim-lang.org
nim-lang.org
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!
Note that at one point it could even do multi-methods (dynamic dispatch on multiple arguments at once), similar to what Julia could do. But this got removed because it complicated the language, had undesirable performance penalties, and was overall hard to maintain (https://github.com/nim-lang/RFCs/issues/65). It's still available via a flag, but might get eventually removed at some point.
Overall, I view Nim as more of a procedural language in the spirit of C/Pascal rather than the OOP-isms of old C++ / Java.
Are you thinking of multiple dispatch? i.e. runtime dispatch on the type of _every_ function argument. It used to have that but they took it out. It still has runtime dispatch on the first argument.
I also found this https://disconnected.systems/blog/nim-on-adruino
I’ve been moving development to Zephyr RTOS since it supports many more boards and is more stable. I’d recommend trying it out but note it’s a WIP. I haven’t figured out templated examples yet. I’ve covered lots of api areas but not all. My goal is to make it into a broad MCU platform for Nim — Nephyr: https://github.com/EmbeddedNim/nephyr
But yah Nim can run on most anywhere you can compile C to. Some people just got Nim CMSIS working. I’m hoping to get more people involved at github.com/EmbeddedNim project to support more mcu’s. Testers are welcome!
But it doesn't run on OSX 10.12.x which is the last OSX version I'll be using for some time.
Nim, on the other hand does. It also does microcontrollers and browsers. Couldn't ask for more.
Programming languages are getting better and better. The standard of adoption is so high that, without major corporate backing (like Kotlin), it takes that long to get the language good enough & "big" enough (in terms of network effects) that people can start to seriously consider using it at work.
Also I think there is somewhat of a pendulum swing occurring in programming languages in general. People seem to be taking an interest in learning more and weirder programming languages, and taking interesting ideas and design patterns from those languages. And a lot of lessons learned from the "Age of Dynamically-Typed Scripting Languages in Production", too.
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.
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.
As biased as I am I strongly disagree. You can get really far with the db drivers that are in the stdlib (the Nim Forum works very well with just db_sqlite which IMO disproves that Nim is useless for web dev). For something more advanced we need somebody who likes working on these kinds of things to write up a few amazing async db drivers in Nim :)