Yep. This has also been discussed a lot, including recently on this forum:
I linked to an issue and discussion on that thread:
You can read through it all. The upshot is: I don’t think this will be adopted ever because gophers don’t want it for the most part. The go team and developers in the ecosystem are pretty slow to change. That is a good thing and a bad thing.
Many years ago I read The Secrets of Consulting by Weinberg (excellent book btw). In it he has a rule called “The Fast-Food Fallacy” and it always stuck with me.
No difference plus no difference plus no difference plus. . . eventually equals a clear difference.
I’m not saying we should never evolve go (we added generics for example and that has been fine). But I’m OK with being careful about how we evolve it. Change too much and the thing that originally made it a useful tool might get lost. Right now, I think one of the most useful aspects of go is that it is extremely easy to reason about go code. At the expense of brevity. For me, that tradeoff is working really well.