Yes, Google effectively has final say over what goes into golang; that's never going to change. But then again, the same could be said of the cadres of people managing other languages. At the end of the day, SOMEONE has to be in charge, and that someone probably isn't you.
I personally like to have strong leadership behind such fundamental things as languages. I may not agree with all of their decisions, but at least I can count on the stability, which we all need in order to collaborate successfully. With strong leadership, I know I we won't have another Python2 vs Python3 mess.
And the ability to fork is very handy. I've forked my own golang compiler to allow warnings for unused imports, variables, etc [1] because I don't like fighting the compiler during debug or exploratory coding sessions.
> Google effectively has final say over what goes into golang
I'm wondering who has more say, Google or the individuals on the core Go team. My guess is that said people's personal opinion matters a lot more, or rather, almost exclusively.
How exactly would "Google" decide what goes into golang? They pay the Go team to do that, and I have a gut feeling that the Go team will do what the Go team wants to do, and not something else.
I would also be surprised if enough of them didn't have a sufficient amount of "fuck you money" to be able to effectively do what they want even if Google somehow managed to find someone who feels like they have any authority to tell the Go team which way to go (pun not intended).
Yes, I wasn't fully clear: It's the authors who wield the most power. Google as a whole doesn't really care so long as it works for the things they do (and it already does, so they really don't care anymore).
This isn't a case of an evil empire seeking to enslave our minds via a programming language; it's a company open sourcing their internally designed language, and engaging the community to make it more useful outside of Google (and to increase the number of people who use the language, which is always good because it means a greater pool of developers who could possibly work for them).
I personally like to have strong leadership behind such fundamental things as languages. I may not agree with all of their decisions, but at least I can count on the stability, which we all need in order to collaborate successfully. With strong leadership, I know I we won't have another Python2 vs Python3 mess.
And the ability to fork is very handy. I've forked my own golang compiler to allow warnings for unused imports, variables, etc [1] because I don't like fighting the compiler during debug or exploratory coding sessions.
[1] https://github.com/kstenerud/go