It's good to see all the considerations that are going into making Nim even better for version 2.0. I have tried to read through this rather long thread thoroughly, but don't see anywhere a mention of where multi-threading will go other than to mention that **the compiler command line option `--threads:on` will become default** (which would then have the effect that `Thread`'s and `Channel`'s would become available by default as if they were a part of `Prelude`).
I've been away from Nim for some time after trying to help get what has led to `--gc:arc/orc` started for various reasons, for one having been travelling (around Thailand before we got locked down again), and for another I haven't been able to help much as a contributor so have been waiting and watching to see what shook out in this memory management area - I was always somewhat dissatisfied with the Garbage Collection implementation(s), so am very happy with the direction Nim has gone in this regard. So now that `--gc:arc/orc` seem to be getting reasonably stable, I just finished checking to see how `createThread`, passing data through `Channel`'s, and using `threadpool`'s `spawn` have been affected. I must say that I am impressed, as it seems that as long as one satisfies the conditions for `move` semantics as in being last use of that binding, the many compulsory copies seem to have gone away for the most part for `ref` references, although direct passing of `seq`'s and `string`'s still copies - however, as someone once kindly pointed out to me, all one has to do in order to pass them by `ref` is wrap them. And of course we always have the option of dropping to raw `pointer`'s/`ptr T`'s if absolutely necessary, such as currently when passing `Channel`'s to `Thread`'s (or, I assume, if passing them as an argument to a `spawn`). **So the point of this post is to ask: Is the above a reasonable statement of the capabilities of Multi-Threading currently and are there other changes proposed for Multi-Threading for the newer versions going forward?** This is actually a post that applies not just in this thread, but also to the "Documentation" thread and to the "How to make Nim more popular" thread; for the former, if Multi-Threading now works as it is going to work over the long haul and for the latter in improving the apparent stability of the language, as follows: 1) **The documentation for these multi-threading functions should be updated** to explain better how copying can be avoided by the use of `move` semantics and the work arounds to avoid copying better documented with examples; **If these have reached a fairly stable status, I would undertake to do these documentation updates through the documentation "edit" links.** 2) **In making Nim popular, one of the things that greatly hinder the ready adoption** by people who browse all kinds of different languages, such as myself, is when we encounter **unstable features.** **One such** [is the threadpool library](https://nim-lang.org/docs/threadpool.html) **, which says right at the top that it is an "Unstable API".** As someone who likes to dabble with multi-threading applications, about the only thing that impressed me about GoLang was how easy it was to use "go routines" and Go's Channels along with some basic Lock facilities to implement multi-threaded applications. The `threadpool` library's `spawn` and even `parallel` promise **to make multi-threading about as easy in Nim as in GoLang, but whoa, what about that Unstable tag?** Are we far enough along that we can stabilize the API for Nim version 2.0? It seems to me that `--gc:Arc/Orc` would make these easier than when they had to work through the non-sharing Garbage Collector which was the default in the past. As a minor aside, it seems quite dated that the `threadpool` library has a fixed limit of "only" 32 distinct (hardware reflecting?) threads, where one can reasonably easily have a computer based on something like the AMD Threadripper CPU that has 64 cores and 128 threads, with the ceiling continually being raised. of course, we just need to change the constant and recompile from source, but just saying... With the improvements that seem to be in the pipeline, Nim will continue to be one of my favorite languages, with the other two being GHC Haskell (with my major dislike that can't be worked around being that it is garbage collected) and F#, especially that it is now Open Source as is the Dotnet Core on which it runs (with my major dislikes that it also depends on garbage collection and that it is a JIT compiled language rather than being compiled directly to machine language). My bias is clearly toward functional programming, but with Nim I don't really miss that it isn't really a functional programming language as it allows one to program with functional programming principles in mind: yes, one must use loops instead of recursive functions, but they can be written to reflect the loops that many functional compilers generate internally anyway, as to currying and better pattern matching among other things, it's interesting how little they are missed within using the tools that Nim does provide. I'm sure many of the rest of you have similar feelings.
