As there is already an external package for this, why does this need to live in the standard library? https://golang.org/doc/faq#x_in_std

@ianlancetaylor in my personal and subjective opinion because:

a) It is quite peculiar for a programming language aimed at writing programs for servers to miss such important functionality from its STL.

b) To my knowledge there is only one external package that provides such functionality and that one looks to be in a semi-abandoned state. With 1 star and 7 forks it might as well disappear overnight at the whim of the maintainer. On the other hand Go has a much larger community, hence much more manpower at its disposal. Having a piece of functionality added to Go's STL offers a much better guarantee to the user.

such important functionality

Remember that this is subjective. I think you've shown that the vast majority of Go programmers have never needed such a feature. Otherwise, a popular third party library would exist.

hence much more manpower at its disposal

You're essentially asking that the Go project write and maintain extra software. That does not come for free, and there are limited resources. There are already too many open standard library packages which require more attention than what they're currently getting; just look at the issue tracker and the backlog of patches waiting for reviews.

So, all in all, Ian's reply still stands - if you think this is important, the first step is to maintain it elsewhere and let it become popular.

I think you've shown that the vast majority of Go programmers have never needed such a feature.

No, I don't think I've shown that. I couldn't have. I haven't surveyed the vast majority of Go programmers so that I can talk about their particular needs.

Otherwise, a popular third party library would exist.

It is not guaranteed that a largely spread "need" automatically leads to the availability and increase in popularity of third party libs. It is easy to find at least one counter-example: Go & Generics. People have been screaming for their addition to Go since ages, however a quick search returns only 2 third party implementations, namely genny and generics; and if judged on the bases of stars and forks, none of them will be found guilty of popularity.

You're essentially asking that the Go project write and maintain extra software.

I am merely asking the Go maintainers to consider the addition of machine-wide mutexes to the STL. I personally see this not as much as adding a new feature, but rather finishing what was already started. To me the sync package feels unfinished.

I'm not saying that you need a survey of all Go programmers. But you claim that this is an important functionality with little evidence.

I don't think generics can be compared here. They can't really be implemented outside of the Go project itself, unless you use heavy amounts of code generation.

It's entirely fair for you to think the sync package needs more APIs, but it's also entirely fair for the maintainers to disagree. That's why the FAQ entry exists :)

Apart from whether this is needed, or needed in the stdlib (I agree with @mvdan here), I don't really understand the semantics, and I don't understand how we might implement it. Those both argue for a prototype outside the stdlib as a first step.

As long as every process behaves well, it works. But what happens when some process doesn't release the lock? Does it go into some sort of abandoned state? How do we get back from that state?

How do we implement this? It has to interact with the OS somehow. How? Do all the OSes we support have the capabilities we need to implement this feature? Do we need to be compatible with other languages on the same platform, so people can have cross-language locks?

But you claim that this is an important functionality with little evidence.

@mvdn you are basically asking me to prove that

A) People need IPC in Go applications
B) People need fast IPC in Go applications (achievable only with shared memory + machine wide mutex)
C) It happens often enough to be considered important

Point C) above I can't prove nor can you disprove for that matter. While A) and B) are truisms and unfortunately I have no idea how to prove something self-evident, especially when I have no idea what your standard of proof is.

It's entirely fair for you to think the sync package needs more APIs, but it's also entirely fair for the maintainers to disagree.

Absolutely.

@randall77

Apart from whether this is needed, or needed in the stdlib (I agree with @mvdan here), I don't really understand the semantics, and I don't understand how we might implement it. Those both argue for a prototype outside the stdlib as a first step.

There is this: juju . It claims Linux, MacOS and Windows support. No idea how many platforms is Go supposed to officially support. Probably the above + BSD & Solaris according to Wikipedia.

Perhaps #33974 would be an acceptable approach to this.