5 ms·

Nim Community Survey

81 points by generichuman 5y ago

goodpoint 5y ago
Wonderful!
icey 5y ago
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.
anaphor 5y ago
I would really like to see more work on improving the use of Nim for programming microcontrollers. I stumbled on to https://github.com/elcritch/nesper https://github.com/elcritch/nesper 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). I also found this https://disconnected.systems/blog/nim-on-adruino https://disconnected.systems/blog/nim-on-adruino
- elcritch 5y ago
  Nesper author here, unfortunately I haven’t had time to fix the compile issues on all the esp-idf branches. Please feel free to file an issue as I don’t use es-idf/Nesper often now but I’ll respond to issues. The main branch should be more stable too. 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 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!
  - anaphor 5y ago
    That's awesome. I didn't file an issue yet but I was hoping to try it again soon and get a better idea of what's going wrong first.
rishav_sharan 5y ago
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. 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.
- cyber_kinetist 5y ago
  The more desperate thing that Nim currently needs is better tooling to create bindings for C libraries. c2nim fails to work in a lot of cases, and nimterop still needs a bit more work.
  - anaphor 5y ago
    You can always call the C functions directly (from a shared lib) although admittedly it's a pain because you have to deal with unmanaged pointers very often.
- dom96 5y ago
  > The current driver are terrible and are the main reason why Nim is practically useless for web dev. 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 :)
  - rishav_sharan 5y ago
    Hey Dom. I realise that my tone of commenting was unnecessarily hostile. I apologise about that. I love nim and wish the best to it, but I think you will also agree that an async driver for databases like PG are the lowest and ripest hanging fruits to take nim webdev to the next level.
captainmuon 5y ago
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!
- cyber_kinetist 5y ago
  Nim supports runtime polymorphism, you need to use the ``method`` keyword instead of ``proc`` to achieve dynamic dispatch. (https://nim-lang.org/docs/tut2.html#object-oriented-programming-dynamic-dispatch https://nim-lang.org/docs/tut2.html#object-oriented-programm...) 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 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.
db65edfc7996 5y ago
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.
- abzug 5y ago
  I want it too but Nim is 13 years old so not a young language. Compare it to Zig, which is 5 years old and I don't see it coming anywhere outside its niche.
  - godDLL 5y ago
    I liked Zig. I liked it a lot. 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.
  - nerdponx 5y ago
    A lot of the "up-and-coming" languages out there are on the order of 10 years old. 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.
MrMan 5y ago
Ide support Numpy/pandas port
- pietroppeter 5y ago
  Vs code is pretty well supported. Numpy -> Arraymancer, Pandas (better, dplyr) -> Datamancer
rsyring 5y ago
Need an option in the survey for "want to use" and then get feedback on what's holding the user back.
nomemory 5y ago
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...
- kevin_thibedeau 5y ago
  Perl, Ruby, PHP, and others didn't have corporate support before gaining popularity.

81 points by generichuman 5y ago

Wonderful!

icey 5y ago

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.

anaphor 5y ago

I would really like to see more work on improving the use of Nim for programming microcontrollers. I stumbled on to https://github.com/elcritch/nesper https://github.com/elcritch/nesper 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). I also found this https://disconnected.systems/blog/nim-on-adruino https://disconnected.systems/blog/nim-on-adruino

elcritch 5y ago
Nesper author here, unfortunately I haven’t had time to fix the compile issues on all the esp-idf branches. Please feel free to file an issue as I don’t use es-idf/Nesper often now but I’ll respond to issues. The main branch should be more stable too. 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 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!
- anaphor 5y ago
  That's awesome. I didn't file an issue yet but I was hoping to try it again soon and get a better idea of what's going wrong first.

rishav_sharan 5y ago

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. 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.

cyber_kinetist 5y ago
The more desperate thing that Nim currently needs is better tooling to create bindings for C libraries. c2nim fails to work in a lot of cases, and nimterop still needs a bit more work.
- anaphor 5y ago
  You can always call the C functions directly (from a shared lib) although admittedly it's a pain because you have to deal with unmanaged pointers very often.
dom96 5y ago
> The current driver are terrible and are the main reason why Nim is practically useless for web dev. 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 :)
- rishav_sharan 5y ago
  Hey Dom. I realise that my tone of commenting was unnecessarily hostile. I apologise about that. I love nim and wish the best to it, but I think you will also agree that an async driver for databases like PG are the lowest and ripest hanging fruits to take nim webdev to the next level.

captainmuon 5y ago

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!

cyber_kinetist 5y ago
Nim supports runtime polymorphism, you need to use the ``method`` keyword instead of ``proc`` to achieve dynamic dispatch. (https://nim-lang.org/docs/tut2.html#object-oriented-programming-dynamic-dispatch https://nim-lang.org/docs/tut2.html#object-oriented-programm...) 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 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.

db65edfc7996 5y ago

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.

abzug 5y ago
I want it too but Nim is 13 years old so not a young language. Compare it to Zig, which is 5 years old and I don't see it coming anywhere outside its niche.
- godDLL 5y ago
  I liked Zig. I liked it a lot. 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.
- nerdponx 5y ago
  A lot of the "up-and-coming" languages out there are on the order of 10 years old. 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.

MrMan 5y ago

Ide support Numpy/pandas port

pietroppeter 5y ago
Vs code is pretty well supported. Numpy -> Arraymancer, Pandas (better, dplyr) -> Datamancer

rsyring 5y ago

Need an option in the survey for "want to use" and then get feedback on what's holding the user back.

nomemory 5y ago

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...

kevin_thibedeau 5y ago
Perl, Ruby, PHP, and others didn't have corporate support before gaining popularity.