There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.
That is a very unusual definition of "type safety." What you're describing is more commonly known as "thread safety," in my experience.
By your definition, is Java type safe? You still need to guard against concurrent mutation of shared data in Java and in most other languages that support shared mutable state.
We typically describe Go as "memory safe," in that you can't address uninitialized memory (unless you import package "unsafe", which clearly demonstrates your intent).
Java is type safe, because the language defines clear semantics for what happens when you mutate two memory locations simultaneously (you get one result or the other). Under no circumstances does the program have truly undefined behavior. Java HashMaps aren't thread-safe, but they will just do the wrong thing when you try to access them concurrently. Under no circumstances will the program be able to read or write undefined memory.
By contrast, your Go program's behavior becomes undefined when you mutate and read a hashmap concurrently among multiple threads. Anything can happen.
Edit (addressing the reply below): That's fascinating, thanks. It really speaks to the wisdom of writing hash maps in the library, on top of the language, rather than unsafely in the runtime as Go does. (This would unfortunately require generics, so it's not an option for Go.)
It's very difficult to predict all that can go wrong with unsynchronized access to data structures that aren't designed to be thread safe. The beauty of Java here is that the core primitives can never lead to accessing undefined memory, and therefore hash tables, however badly they mess up, will never lead to that core principle being violated. This is critical for security, for example.
I agree with everything you've said in this thread, except this: "type safety" should mean that the system has some belief about the type of values that cannot be compromised.
(sometimes type safety can be proven absolutely by static checking, but you have otherwise only run-time type checking, e.g. dynamic JVM languages, introspection).
Unlimited memory corruption does seem to imply that run-time type guarantees are gone, but it's still better to use the most appropriate terms.
