In general, Go has a sort of "good enough" or very pragmatic philosophy. It offloads strict enforcement of non-sharing between goroutines to the user and community best practices, but provides no compiler enforcement, which would be very difficult due to the fact that the entire rest of the language is mutable.

Erlang's design was driven by much stronger philosophical principles and an unusual initial use case (phone switch programming).

I'm not saying either is necessarily better and worse. The end result is that Go is a much more mainstream language with a lot of refinements, and Erlang is the sort of bizarre-but-oddly-useful language you get when a strong philosophy is carried through to its full logical conclusion. (See also Haskell.)

If you really, really care about compiler-enforced safety, Go is not a good choice. Not only will it let you shoot yourself in the foot, it won't really do that much to stop you. (Indeed, this presentation is almost terrifying from the perspective of an Erlang programmer, so many ways to screw up with the compiler only noticing a handful of them: [1] slides: [2]) However, if you're sort of interested in the sorts of things that can give you but aren't ready to put on the hair-shirt (a metaphor from the Haskell community), Go has some ways of putting your toes into the water and getting some of the practical benefits without a ton of the theory, for instance: http://www.jerf.org/iri/post/2923 . (Only some though.)

[1]: http://www.youtube.com/watch?v=QDDwwePbDtw

[2]: http://talks.golang.org/2013/advconc.slide