In a concurrent language, shared mutable state is the trap that Hoare's CSP book was urging us to avoid. Worse, in Go builtin maps are always writable yet parallel writes and reads can segfault. There's a sync.Map type but it isn't a drop-in replacement (because builtin maps don't implement any interfaces) and it isn't typesafe (because no generics).

Yes, Go has very bad primitives whichever way you look at them. I still think you can't say a language with built-in immutability is more boring technology than one with built-in mutability.

There's nothing stopping you from using Go's maps without mutation. You can go ahead and send copies of maps through channels, just like you would if they were really immutable. Sure, the interface is clunky, but so is every other interface in Go, so I don't see too much reason to complain here...

It is fine to use local mutable variables to implement an algorithm, however global objects modified all over a complex program can be risky - you might have bugs caused by getting into an "unexpected" state.

And what does that have to do with everything being immutable by default? Either the language supports mutability as a first-class concept, or it doesn't. Sure, you shouldn't be using mutable global state, either in Go or in Haskell.

The bad part about Go is that it's impossible to write type-safe immutable collections. Apart from that, I don't think it encourages mutable global state anymore than any other language with first-class mutation.