Nim Community Survey

https://nim-lang.org/blog/2021/11/22/community-survey-2021.html

by generichuman • 5 years ago

81 22 5 years ago

goodpoint• 5 years ago

Wonderful!

icey• 5 years 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.

anaphor3• 5 years 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 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

elcritch• 5 years 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

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!

anaphor3• 5 years 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_sharan2• 5 years 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_kinetist2• 5 years 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.

anaphor3• 5 years 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• 5 years 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_sharan2• 5 years 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• 5 years 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_kinetist2• 5 years 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-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). 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.

_dain_• 5 years ago

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

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.

db65edfc7996• 5 years 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• 5 years 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• 5 years 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• 5 years 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• 5 years ago

Ide support Numpy/pandas port

pietroppeter• 5 years ago

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

rsyring• 5 years ago

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

nomemory• 5 years 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• 5 years ago

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

Nim Community Survey

Related Stories