5 ms·

Go is problematic as a systems language. Calling it safe is odd, when it's glaringly allowed for Null. It's safe like Java is safe, which means that the memory

Go is problematic as a systems language. Calling it safe is odd, when it's glaringly allowed for Null. It's safe like Java is safe, which means that the memory will always be safe to use, but the program will still die due to bugs that a compiler could have helped prevent. As a comparison Rust has no runtime, has no garbage collector, and is a pure systems language, and also helps developers be truly safe. Based on my experience with Go, I still don't understand where it fits, it's a compiled language, but has a runtime and a GC. So it's somewhere between C++ and Java, it's less verbose and faster to program in, but if that's the desire, than perhaps the better choice will be Kotlin in the long run.

brobinson 11y ago
> which means that the memory will always be safe to use In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access". A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim? [1] http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-co...
- dbaupp 11y ago
  Dereferencing nil is not an unsafe memory access in Go, just like a null pointer exception in Java isn't unsafe. Both are well-defined operations (sure, they yield errors, but they do so with 100% reliability and complete control), they're not undefined behaviour like in C or C++. Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)
  - brobinson 11y ago
    Thanks for the clarification! What if instead of the sender goroutine setting the pointer to nil, the GC frees the object that the pointer was pointing to before the recipient goroutine reads it? Wouldn't that be considered "reading from a pointer that has already been freed"?
    - ustolemyname 11y ago
      That can't happen. The GC won't free the object until nothing references it, and in your proposed scenario either the channel or receiving goroutine will have a valid reference.
      - brobinson 11y ago
        Thanks for the explanation. I didn't realize Go's GC also worked for pointers/references.
        brobinson 11y ago
        Let me qualify that: work for them across goroutines
nzoschke 11y ago
Great points and comparison to Rust. I'll tweak my view. Go is a pragmatic systems language. It's design and tooling is better than scripting languages for systems glue. There will be many places where it's not suitable vs C or Rust.

brobinson 11y ago

> which means that the memory will always be safe to use In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access". A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim? [1] http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-co...

dbaupp 11y ago
Dereferencing nil is not an unsafe memory access in Go, just like a null pointer exception in Java isn't unsafe. Both are well-defined operations (sure, they yield errors, but they do so with 100% reliability and complete control), they're not undefined behaviour like in C or C++. Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)
- brobinson 11y ago
  Thanks for the clarification! What if instead of the sender goroutine setting the pointer to nil, the GC frees the object that the pointer was pointing to before the recipient goroutine reads it? Wouldn't that be considered "reading from a pointer that has already been freed"?
  - ustolemyname 11y ago
    That can't happen. The GC won't free the object until nothing references it, and in your proposed scenario either the channel or receiving goroutine will have a valid reference.
    - brobinson 11y ago
      Thanks for the explanation. I didn't realize Go's GC also worked for pointers/references.
      - brobinson 11y ago
        Let me qualify that: work for them across goroutines

nzoschke 11y ago

Great points and comparison to Rust. I'll tweak my view. Go is a pragmatic systems language. It's design and tooling is better than scripting languages for systems glue. There will be many places where it's not suitable vs C or Rust.