Why doesn't Go support map concurrency at the language level?

Hello everyone, I am fried fish.

When many small partners learn the grammar of the Go language, they may only see this problem lightly, but once they get started, they will encounter it a few times in a group more or less.

Even programmers with a certain age will find it. Some friends are wondering, so tossing, why doesn't Go directly support map concurrency at the language level, how fragrant is that?

Why is it not natively supported?

Why doesn't Go officially support it? Is it too complicated and the performance is too poor. Why?

The official answer is as follows (via @go faq):

• Typical usage scenario: A typical usage scenario for map is that safe access from multiple goroutines is not required.
• Atypical scenarios (requires atomic operations): The map may be part of some larger data structure or an already synchronized computation.
• Performance scenario considerations: If only a few programs are added to the security, all operations of the map have to deal with mutex, which will reduce the performance of most programs.

The core is: after a long discussion, the Go team believes that native maps should be more suitable for typical usage scenarios.

For a small number of cases, using will cause most programs to pay a performance price of , which determines that native concurrent map read and write is not supported. And since Go1.6, added a detection mechanism , which will cause exceptions if it is concurrent.

why crash

As mentioned earlier, the concurrency detection of native maps will be performed since Go1.6, which is a "nightmare" for some people.

Some people complained here: "It's okay to throw me a mistake, why should I let my Go process crash directly and give me a P0 every minute".

scene enumeration

Here we assume that if the concurrent read and write map is the following two scenarios:

1. Generate panic: program panic -> walks into recover by default -> does not process concurrent map -> map has dirty data -> program uses dirty data -> generates **unknown ((Influence.
2. Generate crash: program crash -> crash directly -> save data (data is normal) -> generate **clear ((risk.

Which option would you choose? Go officials chose the second one in the risk measurement of the two.

Whether it's programming or life. How to grasp the deterministic part of randomness is also a great philosophy.

let it crash

The method chosen by the Go official team is the classic "let it crash" behavior in the industry, which is adopted as a design philosophy in many programming languages.

let it crash means that engineers don't have to worry too much about unknown bugs and go for comprehensive defensive coding .

The most classic of this concept is erlang.

Summarize

In today's article, we introduced why the Go language does not support native support for map concurrency. The core reason is that most scenarios do not need it, considering performance considerations.

The reason to directly read and write the map concurrently is to consider "let it crash". If you want to avoid this situation in your own project, you can add race detection (-race) to tool chains such as linter, and you can also avoid such risks.

What do you think of the design considerations for Go? Welcome to leave a message and exchange in the comment area :)

If you have any questions, welcome feedback and exchange in the comment area. The is to achieve each other . Your likes is fried fish create, thank you for your support.

The article is continuously updated, you can read it on search [Brain into the fried fish], this article 161de5958b4393 GitHub github.com/eddycjy/blog has been included, learn Go language, you can see Go learning map and route