You get weird little unexplained panics, more or less. Stuff like nil pointer references, errors with map/slice access, and deadlocks.

In theory the failures could be pretty insidious - data could be corrupted without any crash, or in a way that causes a crash in an almost unrelated part of the program. I have no idea how likely the really squirrelly failure modes are, but there will be much scratching of heads and gnashing of teeth when they do pop up. The race detector probably helps a lot.

You can segfault with arbitrary undefined behavior [1], but I've never heard of it happening in practice.

[1]: http://research.swtch.com/gorace

Setting something to nil and then referencing it is a trivial race condition to create which can cause a crash.

Thanks for this response, and all the others. For some reason I had it in my head that Go's CSP concurrency model precluded sharing of that kind.

Golang's CSP idiom precludes that sharing. The language itself was explicitly designed not to preclude it: if you know what you're doing (or, unfortunately, don't), you can easily design concurrent data structures using locks or atomic operations. Golang doesn't even cordon this stuff off as "unsafe"; like in most languages, shared mutable is the default.

That said: unlike, say, string counting idioms in C, the share-using-channel idiom in Golang is powerful, in the sense of: it's what most people reach for by default.

For a language as opinionated as Golang, it's extraordinarily pragmatic. It is designed first and foremost to be a tool, and then a lot of other things, before being a statement about how to design safe programs.

I don't actually know of a single language that has locks and atomics, but marks them unsafe. All languages I know of either have them and mark them safe and idiomatic (for example, Golang or Rust), or don't have them at all (for example, Erlang).