Hello, I’m fried fish.

Many friends may have only seen this problem lightly when learning the grammar of Go language. As a result, once they get used to it, they will encounter this problem several times in a group.

Even programmers of a certain age will be found to encounter it. Why doesn’t Go support map concurrency directly at the language level?

Why is native not supported

Why don’t Go officials support it, it’s too complicated, the performance is too bad, why on earth?

The official reasons are as follows (via @go FAQ) :

  • Typical use case: A typical use case for a map is that secure access from multiple Goroutines is not required.
  • Atypical scenario (atomic manipulation required) : THE map may be part of some larger data structure or already synchronized computation.
  • Performance scenario consideration: Adding security to a small number of applications, causing all map operations to process MUtex, would degrade the performance of most applications.

The bottom line is that the Go team, after a long discussion, decided that the native map was better suited to typical usage scenarios.

For a small number of cases, most applications will pay a performance price, deciding not to support native concurrent map reads and writes. And since Go1.6, the detection mechanism has been added, which will lead to exceptions if it is concurrent.

Why is it breaking down?

As mentioned earlier, concurrent detection of native maps will be implemented in Go1.6, which is a “nightmare” for some people.

“Why should I crash my Go process when I could have made a mistake? Give me a P0 in a minute.”

Scenario enumeration

Let’s assume that the map is read and written concurrently in the following two scenarios:

  1. Create panic: program panic -> default into recover -> no concurrent map processing -> map has dirty data -> program using dirty data -> cause ** unknown ((impact).
  2. Crash: program crash -> crash -> save data (data normal) -> create ** clear ((risk).

Which option would you choose? Go officials chose the second of the two risk measures.

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

let it crash

The approach chosen by the Go team is the classic “let it Crash” behavior that many programming languages embrace as a design philosophy.

Let it crash means that engineers do not have to worry too much about unknown errors, but instead do defensive coding that covers everything.

The best example of this concept is Erlang.

conclusion

In today’s article, we explain why the Go language does not support map concurrency natively. The core reason is that most scenarios do not need it for performance reasons.

The reason for directly allowing concurrent map reads and writes is to think in terms of “let it crash”. If you want to avoid this in your own projects, you can also avoid this risk by adding -race detection to tool chains like Linter.

What do you think of the design considerations for Go? Feel free to comment in the comments section 🙂

If you have any questions, welcome feedback and communication in the comments section. The best relationship is mutual achievement. Your praise is the biggest motivation for the creation of fried fish, thank you for your support.

This article is constantly updated. You can read it on wechat by searching “Brain into fried fish”. GitHub github.com/eddycjy/blo… Already included, learning Go language can see Go learning map and route, welcome Star urged more.