3 ms·

> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsaf

> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't any.

thanatos_dem 8y ago
...Are you really trying to use “gophers” as a derogatory term?
- Retra 8y ago
  Doesn't look like it. Looks like they are just using it for artistic flourish.
- kjeetgill 8y ago
  Many Go programmers refer to themselves as Gophers actually after the mascot the same way university students might refer to them selves as Jaguars, Titians, or Aggies. It's hard to google a good example but here's one I found: > A creative and passionate community of Go developers and users (“Gophers”) has grown up around the language, and today there are U.S. Go conferences, European Go conferences, […] even a group for LGBT Gophers (yes, “Gayphers”). https://blog.newrelic.com/technology/golang-experts-follow-online/ https://blog.newrelic.com/technology/golang-experts-follow-o...
leshow 8y ago
> And yes, sequential Go _is_ memory safe, but concurrent Go is not. You're agreeing with me, I was saying that Go isn't memory safe by Rusts definition. As you mentioned, it doesn't protect against data races, therefore, when Go claims memory safety they are using some different definition of memory safe.