3 ms·

I think the article inadvertently reinforces the idea that it's really only practical to scale code that segregates processes and uses streams instead of shared

I think the article inadvertently reinforces the idea that it's really only practical to scale code that segregates processes and uses streams instead of shared memory. New languages should probably focus on things like the Actor model and optimize stream passing with things like copy-on-write so that no data is actually copied until it's mutated. For this and many other reasons (mainly pushing the onus of managing memory onto the developer instead of automating it) I can't really get behind Rust. I think many other languages like Swift are also barking up the wrong tree by being too pedantic.

Veedrac 9y ago
These problems (and the mistakes thereof) wouldn't happen between Rust threads, because the typesystem is explicitly designed to handle that safely. It's only when you're introducing type-unsafe boundaries where these problems occur, and the best solution to that is typically to use a wrapper that creates a type-safe abstraction. Supposedly Neon handles this for Node.
dbaupp 9y ago
Rust puts a reasonably large amount of effort into making shared memory concurrency safe. Move semantics, borrow checking and the Send/Sync traits combine to eliminate/reduce many of the pitfalls (e.g. data races) which motivated people to move away from shared memory. Additionally, Rust's semantics mean that things like actors/message passing and copy-on-write can be very efficient (e.g. move semantics means any copy-on-write overhead doesn't need to exist if the code will statically never read/write concurrently): http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... Of course, the fairly explicit nature of Rust is annoying/inappropriate for some tasks which don't need quite that level of control, but I think you're missing the power Rust brings to concurrency. (Of course, whether this particular article uses that power is a different question.)

Veedrac 9y ago

These problems (and the mistakes thereof) wouldn't happen between Rust threads, because the typesystem is explicitly designed to handle that safely. It's only when you're introducing type-unsafe boundaries where these problems occur, and the best solution to that is typically to use a wrapper that creates a type-safe abstraction. Supposedly Neon handles this for Node.

dbaupp 9y ago

Rust puts a reasonably large amount of effort into making shared memory concurrency safe. Move semantics, borrow checking and the Send/Sync traits combine to eliminate/reduce many of the pitfalls (e.g. data races) which motivated people to move away from shared memory. Additionally, Rust's semantics mean that things like actors/message passing and copy-on-write can be very efficient (e.g. move semantics means any copy-on-write overhead doesn't need to exist if the code will statically never read/write concurrently): http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... Of course, the fairly explicit nature of Rust is annoying/inappropriate for some tasks which don't need quite that level of control, but I think you're missing the power Rust brings to concurrency. (Of course, whether this particular article uses that power is a different question.)