Why Do Go Developers Debate Reentrant Locks? Insights from a Community Poll

Hello, I'm Xiao Lou. A few days ago I published an article titled "Is This Another Go BUG?" which unexpectedly generated strong discussion.

At the end of that article I added a poll on whether Go's read‑write lock is reasonable. 62 people voted, with a conversion rate of about 10% from article views to votes.

The poll results showed 58% chose "reasonable", indicating most readers support Go's approach, though some still find it questionable.

Below are five representative comments from the community that prompted further reflection:

1. Why lock twice?

The duplicate lock was a typo, but readers wondered why it was added. A more constructive answer suggests enabling the race detector to catch such issues early.

2. Go doesn't work that way

Initially I thought Java's design was superior, but after the discussion I realized both languages have merits.

One statement I made was inaccurate: the term "re‑entrant lock" would be better translated as "recursive lock"; Go's read and write locks are not re‑entrant.

3. Re‑entrant locks are "garbage" design?

As a Java developer I value usability, and many Java developers favor re‑entrant locks, yet some Gophers consider them a poor design.

4. Communication over shared memory

Go's mantra "don't communicate by sharing memory; instead share memory by communicating" still feels unclear to me, and I seek a convincing explanation.

5. Go simply doesn't want to implement it

One commenter suggested that Go could implement re‑entrant locks but perhaps chooses not to for philosophical reasons.

In conclusion, the feedback and discussion have convinced me to study Go's underlying mechanisms more systematically, and I may share that learning journey in future articles.