@carterza: I bet, if you opened the thread with your last post it would have gotten a much more positive reception. I can see a lot of valid and deliberate critique there, even though my personal experience with Nim is short and superficial, compared to most active folks here.
> All of this work should be documented and centralized. ... Nothing has any > association with any ongoing project or anything so there's literally no > visibility into what is going on in Nim development at any one moment, so > even if people wanted to get involved in some aspect of Nim's development, > it's difficult. Tagging issues as easy and writing a paragraph or two about > how to get involved, simply isn't enough guys... ... Nim basically lacks a > person in a project and / or product manager role, to a very large degree. This resonates with me and is essentially the same thought that led me to start this thread: [Improving the documentation: Roadmap, community engagement.](https://forum.nim-lang.org/t/8091) To which I was suggested to Shut Up 'N <s>Play Yer Guitar</s> Make Yer PRs, which is perfectly reasonable, but doesn't address the request of providing some coordination of efforts. Regarding teaching material and books: we need more, of course, but realistically, there's not enough hands to take care of the existing stuff. The attitude toward Dr. Salewski's book is a bit strange. Even though the book might be seen as not 100% technically sound and has some raw English bits, it decisively can't bring more harm than benefits for the reader. I think it would be cool if it was at least neutrally mentioned/linked more, if not promoted. Re multithreading: at least we now have working `threading`. While a working `spawn` would be nice too, I think Nim primarily lacks stable and tested threadpool for arc/orc. Of course, docs should stress out `threading/channels` is the thing to use by default (as does D, for example). @mratsim: > For sequtils/strutils, I think those should be completely revamped to use > either iterators (require iterator chaining) or composable views (requires > view types as values) or stack-allocated coroutines (using nim-cps) instead > of closure iterators. Yes, pretty please! While composable iterators are my pet-peeve, I just was headed to our chats to ask if there's anyone working on reimplementing `strutils` on top of openArrays, after writing another rather basic func of this sort. Even if the official solution will eventually converge on some other way (listed in the quote above), this alternative part of stdlib could be used _now_ and it's clearly a thing where some coordinated effort could be of use.
