Goodbye Nim, and Good Luck
gradha.github.io
gradha.github.io
He is right that there was some breakage in libraries with 0.96 to 0.10.2 - I'm hoping that things will start to settle once v1.0 is released and Nim will gain more traction.
"This means that a thread cannot touch the memory of another thread."
but has grown a host of smart pointer-based thingys that do exactly that.
(Edit: I realized I forgot Swift -- mea culpa.)
It is also guaranteed by ownership system: in the safe mode (which is default) rust will statically (at compile time) ensures that a value can only be mutated at a single execution point. It is done by moving, instead of copying any value _by default_, unless it is wrapped in some kind of synchronization primitive or implements a _Copy_ trait.
Synchronization primitives themselves are implemented in unsafe mode, thus limiting the unsafe code scope and allowing custom unsafe code which can also be wrapped in safe interface.
Do you mean those langauges are memory safe only in their GC implementation, which uses multiple kernel threads? How does this affect user code? Java and C# still allow you to access memory from other threads without locking.
You can either sacrifice your guarantees or your use of efficient data structures. Of course, you can always wrap the implementation in some "unsafe" designation, and then declare the whole black box to be correct.
Of course, efficient, general-purpose concurrent data structures usually require a GC.
Still, I think Rust design decisions are correct if it wants to fill the C/C++ niche (which I hope it will). That niche is not necessarily meant to provide the best performance (I believe JITs will soon surpass any AOT compiler, and GCs are pretty much a must to support concurrent workloads on many-core servers with huge RAM) but safety and speed in constrained environments or applications where GC/JITs are inappropriate (small RAM/short startup).
But even so, there is a need for good concurrent data stuctures. What I'm wondering is whether Rust provides a way to use the type system alongside concurrent data structures (ARCs don't cut it). Is there a way to say "this pointer is managed by a transactional data structure and can be shared freely among threads"?
(I assume that whatever implementation exists is similar for Rc'ed objects in Rust, assuming Swift is indeed parallel-memory-safe.)
I admit to not being intimately familiar with Swift, but I assume it is (or is aiming to be), because Objective-C objects are all atomically reference counted, and the language makes an effort to section off the unsafe parts (via names like "UnsafeMutablePointer").
> (I assume that whatever implementation exists is similar for Rc'ed objects in Rust, assuming Swift is indeed parallel-memory-safe.)
Rc is not thread safe, but the language and libraries prevent Rc'd objects from ever moving between threads, so the lack of thread safety of Rc doesn't make the language less thread-safe. There is a separate type, Arc, that is thread-safe and can be sent between threads. (Arc also prevents mutation of the protected data without a mutex or atomic operations.) Swift's approach, by contrast (as far as I know) is to atomically reference count all objects. (This approach is inherited from Objective-C, and more broadly Core Foundation. It mirrors COM and various other component systems.)