4 ms·

It’s still memory-safe, so not that big of a gun.

by cube2222 2y ago

gf000 2y ago
Unlike the language, which can segfault on race conditions with e.g. maps..
- pdimitar 2y ago
  Don't forget panics on sending to closed channels. /facepalm
  - masklinn 2y ago
    panics are memory safe, unguarded concurrency can actually punch through memory safety entirely.
    - pdimitar 2y ago
      Oh I agree, thanks for clarifying it. I am just saying that it's a WTF for me. I appreciate Golang's directness but they _really_ could have done a few things much better.
- 0x696C6961 2y ago
  Go is considered a memory safe language.
  - judofyr 2y ago
    Go without concurrency is fully memory safe. However, once you start using goroutines there can be memory corruption and segfaults: https://github.com/golang/go/issues/37484 https://github.com/golang/go/issues/37484. Note that these are not recoverable panics (such as "writing to a close channel"), but causes completely arbitrary behavior: runtime: pointer 0xc00379ac60 to unused region of span span.base()=0xc001794000 span.limit=0xc001795e00 span.state=1 fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) runtime: nelems=8 nalloc=5 previous allocCount=4 nfreed=65535 fatal error: sweep increased allocation count
    - 0x696C6961 2y ago
      > but causes completely arbitrary behavior I think we have different definitions of "arbitrary"
      - gf000 2y ago
        The moment you go off the memory safe route, you have absolutely no way of ever going back - the best case scenario is that the OS catches your wrong-doing and you get a segfault. Everything else might silently corrupt the runtime's state or business data. As they say, here be dragons.
      - judofyr 2y ago
        Please elaborate! What's your definition? I was struggling a bit to phrase it precisely. My main point was to distinguish between "well-defined panic" (which is just like any other panic) and "silent memory corruption which keeps the program running". To me it seems rather arbitrary that appending to a slice concurrently in two different goroutines causes the garbage collector's sweep-phase to internally think another allocation has occurred.

It’s still memory-safe, so not that big of a gun.

gf000 2y ago

Unlike the language, which can segfault on race conditions with e.g. maps..

pdimitar 2y ago
Don't forget panics on sending to closed channels. /facepalm
- masklinn 2y ago
  panics are memory safe, unguarded concurrency can actually punch through memory safety entirely.
  - pdimitar 2y ago
    Oh I agree, thanks for clarifying it. I am just saying that it's a WTF for me. I appreciate Golang's directness but they _really_ could have done a few things much better.
0x696C6961 2y ago
Go is considered a memory safe language.
- judofyr 2y ago
  Go without concurrency is fully memory safe. However, once you start using goroutines there can be memory corruption and segfaults: https://github.com/golang/go/issues/37484 https://github.com/golang/go/issues/37484. Note that these are not recoverable panics (such as "writing to a close channel"), but causes completely arbitrary behavior: runtime: pointer 0xc00379ac60 to unused region of span span.base()=0xc001794000 span.limit=0xc001795e00 span.state=1 fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) runtime: nelems=8 nalloc=5 previous allocCount=4 nfreed=65535 fatal error: sweep increased allocation count
  - 0x696C6961 2y ago
    > but causes completely arbitrary behavior I think we have different definitions of "arbitrary"
    - gf000 2y ago
      The moment you go off the memory safe route, you have absolutely no way of ever going back - the best case scenario is that the OS catches your wrong-doing and you get a segfault. Everything else might silently corrupt the runtime's state or business data. As they say, here be dragons.
    - judofyr 2y ago
      Please elaborate! What's your definition? I was struggling a bit to phrase it precisely. My main point was to distinguish between "well-defined panic" (which is just like any other panic) and "silent memory corruption which keeps the program running". To me it seems rather arbitrary that appending to a slice concurrently in two different goroutines causes the garbage collector's sweep-phase to internally think another allocation has occurred.