4 ms·
Rust has a different notion of memory safety than the Java or Go memory models. In fact, compared to Rust's memory model, both Java and Go are memory unsafe (in
by bascule 12y ago
Rust has a different notion of memory safety than the Java or Go memory models. In fact, compared to Rust's memory model, both Java and Go are memory unsafe (in the Rust sense of safety, not the traditional sense)
Namely, Rust's notion of memory safety prevents data races in concurrent programs. This is because Rust's region typing / lifetime system rejects racy programs as invalid.
Go provides something more like a built-in concurrency framework than truly baking this sort of safety into the language. It's just as possible to write racy concurrent programs in Go as it in in Java, C++, or C.
Go provides idioms that can help you avoid writing racy programs, but they're just that: ideas about how to structure your program, not guarantees that will keep you from shooting yourself in the foot.
Go provides a data race detector so if you do write racy programs, you can retroactively detect the problem. Unfortunately data races have this nasty tendency to pop up under unusual circumstances like high load or unusual combinations of events.
That the author of this post chose concurrency as the thing to harp on about Go's superiority shows how little experience that person has with Rust, IMO. Rust shares the same basic concurrency concepts as Go (communicating sequential processes), but features a compiler whose type system prevents you from writing racy concurrent programs.
- tuxychandru 12y agoRust's multi-threading most certainly is not CSP. CSP requires communication to be synchronous. Rust documentation states that send() will never block and channels have infinite buffer. AFAIK, rust also doesn't allow selecting between a send and receive on channels. It only allows selecting over a set of receivers and even there it doesn't offer something like the default clause of Go's select statement. Rust does have interesting features to prevent data races but it's concurrency model is very different from CSP and Go. Since the author praises Go's concurrency in the context of writing servers, it is entirely reasonable to prefer goroutines over OS threads as the unit concurrency.
- bascule 12y agoRust supports both synchronous and asynchronous message passing over its channels. It's true that asynchronous message passing is generally associated with actor systems and not specifically with CSP, but it's also seen in many extensions of CSP, and in fact CSP and actor systems are duals of each other. Rust supports both approaches.
- tuxychandru 12y agoI was wrong about synchronous communication. Since most rust example use async channels, I missed the existence of sync_channel. However, even if that exists, rust's concurrency doesn't follow CSP as much as go's. Like I mentioned in my previous comment, it doesn't have a way to do everything the select statement in go does. This is not necessarily a bad thing, but rust definitely doesn't share the same concurrency concepts as go. It offers everything that Java/C++ does along with data race protection. Speaking of data race protection, the current type system rejects a lot of very common "non-racy" code too. There is work in progress to address some of them and may be most of them will be addressed eventually.
- bascule 12y ago> doesn't follow CSP as much as go's Because it supports asynchronous messaging too? As if CSP were some concept that emerged fully formed from Tony Hoare's head like Athena from Zeus? I'm sorry you see dichotomies where others see dualities.
- tuxychandru 12y agoI was referring to select statement, not async messaging support.
- bascule 12y agoYou mean like the select! macro in Rust?
- tuxychandru 12y agoNo the select statement of go. It is way more capable that rust's select macro. The tone of your previous comment made me feel that this thread is going in an unproductive direction, so I'll stop here.
- 12y ago