I recently thought about the reason why gintro has only about 100 github stars and so few users. One reason is obviously that the package has a long textual description but only a few tiny pictures. Adding a file dialog pic and maybe a pic of my chess game would help for sure.
The same is even more true for Nim. We could add a prominent link from the landing page to a page called "Show cases" or "Nim in Action". On that page we would show some impressive pictures: A VSCode screenshot, a pic and video of mratsims raytracing video and maybe some data plotting pics.
some vscode pic
https://forum.nim-lang.org/t/6509
https://github.com/brentp/nim-plotly
And maybe some more pics from a game, some GUI pics...
Of course such pics will attract mostly morons, which will then flood IRC and forum for a few months with silly questions and then generally vanish. But maybe under a few dozen morons there is one smart one which may continue using Nim and maybe even contribute.
Of course such pics will attract mostly morons ...
This attitude will destroy any potential community no matter how good the tech or how pretty the pictures.
Stefan, I really liked your post - until the last paragraph. What's wrong with people coming to a new technology ("new" from their perspective) and asking questions to find out if they want to continue with this technology? In my opinion, there's nothing moronic about that, but it's completely normal and legitimate. (By the way, my impression is you get too hung up on "smart" vs. "dumb" people. Everyone is "smart" in some situations and "dumb" in others, that's just human.)
Back to the actual topic, I agree that show-casing uses of Nim on the website could help. Actually, for a little-known language like Nim, a "show, don't tell" approach makes a lot of sense. Without examples and just a description of language features, you can't tell if the language could be useful in theory or if it's actually used (and how).
What's wrong with people
No, there is nothing wrong with them. Maybe moron is not a good term -- I just recently learned that term, maybe Araq taught me. Before I may have thought it is a fruit or a cake :-)
But the fact is that already a few of such unskilled people who refuse to read books or tutorials can block the work of the Nim devs with their questions. IRC logs where full of such questions in the last months, I stopped reading. So I could understand that Nim core devs do not really want to advertise Nim too loud. I personally have no problem with such people, I can just ignore them, as I am not paid.
IRC logs where full of such questions in the last months
you can filter most of them out by blocking discord relay
already a few of such unskilled people who refuse to read books or tutorials can block the work of the Nim devs with their questions
Something neglected in this analysis is that as the community grows, the core devs will not need to answer questions as much. As long as growth is broad-spectrum skills-wise, mid-skills people can pick up that effort. Such social evolution is never "smooth", of course, and whoever can always choose to answer questions. Hot spots of overload/misallocation of human resources is always possible.
could understand that Nim core devs do not really want to advertise Nim too loud
I don't like to speak for people who can well speak for themselves, but I'm pretty sure all the Nim core devs all hope it "catches on".
And another important point for more users would be a weekly blog reporting news about developing and also about some internals.
People are always curious
New packages, new language features, important fxed bug, hired or fired devs, how donations are spent...
So people will came back each week. But again, writing such a blog will keep devs away from doing real work unfortunately.
Hi, I'm very new to Nim, so far it's been an interesting experience. I'll provide my perspective, not to debate it, instead, to share what it's like as I bump into walls and try to figure things out.
My relevant background My day job is managing programmers so all my actual programming time is as a hobby. I was using Haxe prior to this to learn more about game engines and 3D graphics. While using Haxe (JS and HashLink) there were some limitations that frustrated me and so I took a break, deciding instead to take a closer look at Nim. This was after @deech's tweets and a largely positive review from a friend of mine who I initially encouraged to look at Nim (they wanted low-level but weren't jazzed about C/C++/Rust).
My first impression without actually touching the language The docs are pretty good and at least they're organized with links to source so I have a map. I read through the 3 tutorials in about an hour to get an overview, that was easy and it built a map of concepts.
My first impressions actually working with it Both myself and the friend who 'reverse-recommended' it to me were immediately struck by Nim's weak IDE support. Especially given that VS Code and LSP have been such a boon for other smaller language communities we've otherwise encountered. Haxe has a pretty miserable story here too from my perspective, but that's mostly an indication that I've been spoiled rotten by what's available in Java, TypeScript, Kotlin, etc. I don't expect a world class IDE, but my expectations were higher because of Nim's JS target and the existence of nimsuggest and my inferring that meant an easy road to feature rich LSP implementation. This isn't ideal for someone new to the language, but something that can be fixed with a bit of time. If you're wondering why, examples that immediately come to mind: auto-complete is a great way to reduce search space, debuggers are a handy way to learn the gaps between ones mental model vs the implementation, and templates/snippets are a great way to convey subtle style cues.
What I'm currently working on with Nim I figured it wouldn't be that hard to improve the VS Code extension for Nim, I've poked at extensions before and since Nim targets JS this should be a good way to learn Nim. Also, I figured if I helped improve it maybe the community would grow for those going through a similar Nim journey such as myself. So after realizing the extension was written in TypeScript and the most mature LSP implementation seems divorced from I decided to look at converting it to Nim first, you can see my terrible ongoing port of it to Nim here if you're curious. My objectives, learn Nim, improve IDE support, maybe help grow the ecosystem and pave the way for new contributors. At this point I thought, given that the Nim compiler is written in Nim, it targets JS, there is nimsuggest, it'll be awesome!!!
Community impressions thus far One thing to note, as I was googling about and trying to understand why things were the state they were in, I encountered a lot of seemingly acerbic/derisive/vitriolic comments towards VS Code, IDEs, LSP, and so on, they're bit off putting and people are of course entitled to their opinion. Where it went beyond that and honestly I started to have doubts about engaging (including my own hesitation as I write this very message) there was more than one occasion were said criticisms were used to cast aspersions on the users/developers. It's not all doom and gloom, here is a bright spot that as small as it is meant a lot to me, I opened an issue to let the vscode-nim extension folks know I was attempting a Nim port and those little emoji's of encouragement help move past the dips in enthusiasm.
My current opinion things are positive, I'm enjoying myself. I've run into a roadblock with trying to use nimsuggest/sexp parsing in JS and in the midst of an ever expanding search for answers I stumbled upon the forum and this post.
Some challenges I've run into I'm purposefully trying to draw from the beginner mindset and experience so they might seem trivial:
I hope this is useful 'anecdata' for folks here, if someone would like to learn more about my perspective, I'll happily share but I'm not looking to debate it. If you'd be interested in helping me at all with my learning or the porting project, then maybe let's connect outside this thread so it stays on topic.
@Stefan_Salewski:
No, there is nothing wrong with them. Maybe moron is not a good term -- I just recently learned that term, maybe Araq taught me.
Lesson: Don't use words or phrases you don't know well. :-D If in doubt, look up words in a dictionary. I do this all the time, even if I'm "relatively" sure I'm using the right word. If you think you have almost the right word, use a thesaurus. :-)
But the fact is that already a few of such unskilled people who refuse to read books or tutorials [...]
I assume in most cases it's not really "refusing", but that people just assume (not even consciously) that the resources are there to answer questions, even relatively simple ones. Maybe the Nim community seems bigger that it actually is.
IRC logs where full of such questions in the last months, I stopped reading.
I think that's actually a good thing. Not directly, but I'd say it at least suggests that more people get interested in Nim and try it out.
@cblake:
Something neglected in this analysis is that as the community grows, the core devs will not need to answer (basic) questions as much. As long as growth is broad-spectrum skills-wise, mid-skills people can pick up that effort.
Fully agreed. Even I answer questions sometimes if I think I'm qualified. :-)
One other thing: Maybe we need more/better documentation we can point people to for FAQs? That may reduce the questions on IRC somewhat, and even if questions come, we can point to the documentation. Maybe it's possible to extend disruptek's bot so that people can just give the bot some keyword(s) so the bot prints a link to the appropriate documentation?
By the way, as far as questions on IRC are concerned, it's not enough to point people to books or article series. I can completely understand that nobody wants to read a lot of documentation when they're just finding out if the language is for them. I know some people do read lots of docs beforehand (I did), but on average I don't think we should "require" it.
@Stefan_Salewski:
And another important point for more users would be a weekly blog reporting news about developing and also about some internals.
Yes, a regular blog post would be great. It doesn't have to be weekly (although that would be nice, if there's enough to say). For example, I like reading the Sourcehut updates (example). When I got into Nim, I liked the survey results post, but having a blog post only once or twice a year is too little for a sense of progress.
Yes, a regular blog post would be great. It doesn't have to be weekly
It really should be weekly!
In old days tv stations played Columbo weekly, and we all remembered the week day and watched it.
Our physical garbage collector truck comes monthly, and it is really hard to remember.
Another personal example: I read the great Lemire blog nearly weekly for a period of a year. Than I made a break for a few weeks because of too much work. And I never visited his blog again. One reason is that I missed so much and now would have to read for dozen of hours.
So it is definitely weekly blog!