Java had to rewrite the memory model of the whole JVM when they introduced the concurrent package.
Even C++ has a hard time making good use of concurrency and threads because of locking.
My hunch is that because of the way memory works there is no benefit for non GC languages when implementing threads and concurrent memory over many cores.
> My hunch is that because of the way memory works there is no benefit for non GC languages when implementing threads and concurrent memory over many cores.
I've been pretty happy with Rust on multi-core servers, probably because Rust never allows mutable memory to be seen by more than one function.
I've been using async Rust at work, which turns out to particularly interesting, because most of the async executors for Rust can actually move suspended async functions between cores. So you might have dozens and dozens of async routines running across an 8 CPU pool.
There was definitely a bit of a learning curve involved, but we've only ever encountered a single concurrency-related bug, which was a deadlock. (Rust protects against memory corruption, undefined behavior and data races, but not deadlocks.)
Ok, but when you say that they can move between cores, isn't that the OS moving them?
If rust does not allow concurrent memory reads, then that's a big problem in my world.
It seems to me we have a collision between "data driven" and "parallelism on the same memory" in terms of progressing on performance and in that case since I can get parallelism with memory and execution safety with hot-deployment on a VM; the data driven approach does not fit my server side performance needs to the point where I'm able to give those other features up.
Disclaimer: I've done some reading on Rust's concepts but not yet done any substantial coding. Corrections welcome :)
I'm not informed enough to comment on how async works exactly in Rust. However:
> If rust does not allow concurrent memory reads, then that's a big problem in my world.
Note that this is not the goal of the borrow checking system of Rust. You can read memory concurrently just fine (given immutable references to something), you're just not allowed to write to it while you're doing that.
Basically, references in Rust come as immutable (like `const` in C) and mutable, and you're only allowed to have multiple immutable or one mutable reference to the same thing at a time. If you have a mutable reference, you can derive multiple immutable ones from that, but the borrow checker will prevent you from accessing the mutable reference as long as one of the immutable ones is still active (which Rust manages with the concept of "lifetimes").
Java had to rewrite the memory model of the whole JVM when they introduced the concurrent package.
Even C++ has a hard time making good use of concurrency and threads because of locking.
My hunch is that because of the way memory works there is no benefit for non GC languages when implementing threads and concurrent memory over many cores.