1. 16
  1.  

  2. 0

    All of the pains of Go’s shared mutable state concurrency model in a memory unsafe language? Sounds great!

    1. 4

      There’s no pain once you understand that you should use channels instead of access to shared data. Like they put it in their docs, “don’t communicate by sharing memory; share memory by communicating”: https://golang.org/doc/codewalk/sharemem/

      1. 4

        Go still lets you unsafely share mutable state. What you’re describing are merely best practices, the “Doctor, it hurts when I X!” “So don’t X!” approach to concurrency. But without real guarantees from the language, it’s possible you or a library you’re using may slip a pointer into a message somewhere.

        Go added a data race detector for this reason, but data races can only (sometimes) detect races when they happen, i.e. in production, and often under unusual circumstances like high load (i.e. exactly when you don’t want data races to happen)

        1. 1

          Enforceable by value semantics right up until you put an array/slice or map in your struct! D'oh.