Or maybe its because, if the language included them, then people would use them. And that is (almost?) always a bad idea. Not providing a tool that usually leads to code that is hard to maintain, and often incorrect or poorly designed seems to be in line with Go's overall vision. One of the reasons I really like using go is that it allows mediocre programmers to write descent, reasonably solid code. And when working on a team it really matters, because, lets face it, mediocre developers abound.
Ian weighed in on reentrant locks back in the early days: https://groups.google.com/g/golang-nuts/c/4sx5pPp8gFw/m/afBJTrc7UWIJ. There are also many articles on why reentrant locks are evil. Obviously, there are those that disagree. On Tuesday, February 7, 2023 at 8:41:19 AM UTC-5 ren...@ix.netcom.com wrote: > I know this topic comes up a bit and I’ve done a bit more research. > > Is a contributing reason that Go does not have re-entrant locks is that Go > does not have any way to get Go routine identity? It seems you cannot write > a reentrant lock - at least not with the typical syntax - without > specialized runtime support. > > The only public way I can think of is something like > > somelock.Lock(ctx) > > But then you need to make every method accept a context.Context instance. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2db39671-485c-4ee1-ab49-28de41969510n%40googlegroups.com.
