Thanks. If I'm understanding correctly: with Isolated (which is still being built), any given object is reachable from only one thread. It can be used for message-passing but not shared memory.
It looks like they've talked about shared memory as important for efficiency, eg https://nim-lang.org/araq/concurrency.html (from back in 2013 apparently, and I don't know if it's a "canonical" project view or not) says:
> For real CPU efficiency on commodity hardware shared memory is unavoidable. Message passing doesn't cut it and ultimately doesn't address the same problems. (http://www.yosefk.com/blog/parallelism-and-concurrency-need-...) Also shared mutable memory is unavoidable in a systems programming context.
(I agree with that statement, fwiw.)
It sounds like they haven't built support for shared memory yet; correct? and as this Isolated construct is also in progress, I think there's basically no threading support in Nim yet?
Are they still intending to build shared memory as well as Isolated? Is it intended to be memory-safe (as in the Rust terminology) or not?
> It sounds like they haven't built support for shared memory yet; correct? and as this Isolated construct is also in progress, I think there's basically no threading support in Nim yet?
You can do shared memory already. There's concurrent hashes and lists, and full threading support. But currently it's on the programmer to not mess up the GC on shared data (eg ensure data graphs are isolated, but it's not too tricky). I use the ESP32's shared queue data structure in the esp-idf to move Nim's native JSON types between FreeRTOS tasks. It's non-copying and more efficient than normal message passing. I also use some shared globals. It all works pretty well.
I want to remove a couple misunderstandings that I see in the comments.
Nim is "not done" and I hope it never will be. Watch Guy Steele's "Growing a Language" talk for my rationale. We want a language that can continue to evolve and introduce or research new programming language technology.
ARC is scope-based memory management computed at compile-time. It is deterministic and not stop-the-world. If you want to influence the memory management for performance reasons, it's quite trivial to do so by manipulating scopes. There are also knobs and levers if you need direct control of individual allocations.
ORC is ARC but with the tiny addition of a cycle-breaker.
ORC will be the default because it's more convenient than ARC while capturing all of the benefit. It simply adds calls to the cycle-breaker that you may be uninterested in typing in yourself.
Thanks! I was only aware of Nimble. I'll have a look at it.
One thing I noticed right away that it seems to be lacking (judging from the `nimph.json` assuming that is the lock file) are checksums over the data or hashes of revisions the references correspond to. References such as tags are mutable, and thus hashes are needed to validate them. See e.g. the discussion over at https://github.com/NixOS/nix/pull/3216.
