What in the HELL are you talking about? The thread local GC won't even produce anything on the shared heap - it's thread local. Shared memory is manual memory only - Just like C, C++, Ada, and every other manual memory management language. And when the shared GC (which will have to be used explicitly) is implemented - it'll be just like Java, OCaml, and every other shared memory garbage collected language. What in God's does that even mean - segfaults when you use shared memory? It only segfaults if, like in every single other language, you didn't take the time to think out your design and are dereferencing dead memory.

Oh, and I said that it has locks like every other language. I didn't mean shared memory like every other language.

Finally - if you're just being smug at how smart rust is for having lifetime tracking and all those pointer types/restrictions - I don't think it's all that great; Nor did the gaming community when they got their hands on it last; Nor do many others who agree in the opinion that rust is just too complex while being too restricted.

Calm down. All I was saying was that Nimrod is in a somewhat isolated space in which memory management is automatic and safe except for when memory is shared between threads. I'm a bit skeptical of this, because memory management is at its most difficult exactly when multiple threads are involved. So I'm glad to see Nimrod is moving to a thread-safe GC (and I have nothing against Nimrod and would like to see it succeed).

Hybrid automatic and unsafe manual memory management (when the unsafe portion is for something really common like shared memory) is not something I'm really a fan of; it gives up safety while retaining the disadvantages of automatic memory management (lack of control, overhead). I think that safe automatic or fully manual schemes are the ones that have won out in practice because they get to fully exploit the advantages of their choices (safety in one case, control in the other).