If you are accessing variables declared outside the http server, and you use any non-thread safe types or code it will panic.

For instance, try and read a map, it will crash your code.

It won't show this as a problem until you have real traffic on your service.. Hitting it in your browser isn't enough to test properly.

So, accessing shared mutable state from many threads at once is dangerous. It's hard to lay the blame for this on Go - it's true in most languages I know of.

I suppose one ought to guard such maps with a RW lock, or a `sync.Map` which is tailor-made for this kind of situation.

sync.Map is slower than searching a slice of k-v struct for roughly <1000 elements.

Go designed their map implementation to be unsafe for both read and write. I kind of don't care, i was trying to point out something simple and everyone is nitpicking.

Maps are concurrent readonly safe.

You can't declare a read-only map (or slice). Actually Java made exactly the same mistake, the best you can do is to implement Map<K, V> and List<T> with setters that throw at runtime.

They aren't safe to read or write concurrently.

> They aren't safe to read or write concurrently.

Slightly ambiguous wording, so just to clarify:

Go maps are safe to read concurrently

Go maps are not safe to read AND write concurrently

Go maps are not safe to write concurrently

Both!!! Its out there, in the wide world for everyone to read, just use Google!!

I wasn't asking a question, I was clarifying.