4 ms·

The same as any language, if you were to write safe code at least. By safe code I mean, if you wrote Go in such a way that race conditions could not happen, you

The same as any language, if you were to write safe code at least. By safe code I mean, if you wrote Go in such a way that race conditions could not happen, you typically would write it in the same way in Rust. Often this involves Mutexes, but there are plenty of libraries that set up foundations for parallel behavior without Mutexes. So it can operate on "the same memory", and there are a whole lot of ways to manage it safely. The right tool for the right job, really.

whb07 7y ago
this isn't quite right, this feels like what the standard response from a developer with some hubris. Humans are fallible and mushy, and depending on their current state are error prone. So why not just codify some "best practices" that are built in as primitives to a language like Rust? There are ways to perform parallel work that is "safe", Rust solves this with the borrow/checker implementation, another clear "safe" way would be to make everything immutable as seen on Haskell, Ocaml, F# to where who cares about who gets to what first if the underlying thing will never change. Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language.
- asdkhadsj 7y ago
  Sorry, maybe I misunderstood OP. I was responding to what I thought was a general, vague question about how something safe might work in Rust, compared to other languages (Go in my example). So while I don't think what I said was incorrect re: Go vs Rust concurrency, perhaps I misunderstood OPs question. > Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language. I didn't understand OPs question as strictly features cooked into the language, so I was not saying that. With that said, if you're not allowing for Mutexes for "safe things that are cooked into the language" I feel like you won't like Rust. This is an odd metric, though. edit: words

whb07 7y ago

this isn't quite right, this feels like what the standard response from a developer with some hubris. Humans are fallible and mushy, and depending on their current state are error prone. So why not just codify some "best practices" that are built in as primitives to a language like Rust? There are ways to perform parallel work that is "safe", Rust solves this with the borrow/checker implementation, another clear "safe" way would be to make everything immutable as seen on Haskell, Ocaml, F# to where who cares about who gets to what first if the underlying thing will never change. Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language.

asdkhadsj 7y ago
Sorry, maybe I misunderstood OP. I was responding to what I thought was a general, vague question about how something safe might work in Rust, compared to other languages (Go in my example). So while I don't think what I said was incorrect re: Go vs Rust concurrency, perhaps I misunderstood OPs question. > Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language. I didn't understand OPs question as strictly features cooked into the language, so I was not saying that. With that said, if you're not allowing for Mutexes for "safe things that are cooked into the language" I feel like you won't like Rust. This is an odd metric, though. edit: words